[20:08] MatthiasT_ hat den Chatroom betreten.
[20:08] MatthiasT_: servus
[20:09] frunobulax hat den Chatroom betreten.
[20:09] MatthiasT_: Hallo Marcel
[20:09] uho: moin
[20:10] frunobulax: Abend
[20:11] MatthiasT_: Marcel, da hast Du ja eine nette Diskussion in dlf angestoßen
[20:12] frunobulax: A oder B?
[20:12] MatthiasT_: Die A/B ;=)
[20:13] frunobulax: Ich verstand Bernd's Reaktion nicht recht, vielleicht kann er sie noch erweitern.
[20:13] MatthiasT_: Aber so ganz habe ich die X/Y noch nicht verstanden: Wenn man die für den Userpointer und den Framepointer "braucht", wozu macht man sie dann dem Anwender zugänglich?
[20:14] uho: Aha, geht es um Stephens Vorschläge zur Erweiterung der VM?
[20:14] MatthiasT_: A/B scheinen ja mehr Universalregister zu sein
[20:14] frunobulax: Weil es sonst keine Diskussion gibt 
[20:17] BerndPaysan: Hallo!
[20:17] uho: Hallo Bernd!
[20:18] BerndPaysan: Den Userpointer braucht man ja nicht immer
[20:18] BerndPaysan: Und statt Framepointer ist mein zweiter Pointer ja für's OOP gedacht.
[20:18] BerndPaysan: Den braucht man auch nicht immer
[20:20] BerndPaysan: Der Anwender kann dann entscheiden, ob er die Pointer in seiner Routine nicht für etwas besseres nutzen kann.
[20:20] BerndPaysan: Vorausgesetzt natürlich, sie werden gesichert und hinterher wieder restauriert (müssen auch in's Exception Frame)
[20:21] frunobulax: "Den Userpointer braucht man ja nicht immer" ???
[20:22] MatthiasT_: Über USER regele ich u.a. den Task-Wechsel
[20:22] BerndPaysan: Also, in einer kleinen Schleife, die Sachen von A nach B kopiert bestimmt nicht.
[20:22] MatthiasT_: wahrscheinlich ;=)
[20:23] BerndPaysan: Das Hauptproblem sehe ich eher beim Exception-Handling: Das läuft nämlich normalerweise über eine User-Variable 
[20:23] MatthiasT_: Aber A/B wären nach meinem VErständnis ohnehin für den Anwender frei verfügbare Register
[20:23] BerndPaysan: Wenn der UP futsch ist, geht auch kein THROW.
[20:23] BerndPaysan: A/B wären für den Anwender frei.
[20:23] BerndPaysan: Was dann auf x86 keine vernünftige Entscheidung möglich macht: Es sind keine Register mehr da, die für den Anwender freigehalten werden können.
[20:23] MatthiasT_: Und X/Y wären Implementations"empfehlungen"?
[20:23] frunobulax: Vergessen wir X/Y. Problem geloesst.
[20:24] MatthiasT_: Ach, Register habe ich genug.
[20:24] BerndPaysan: Alles außer x86 hat heute ja genügend Register 
[20:24] MatthiasT_: Bei den A/B wären aber neben den Inkrement/Dekrement Zugriffen auch die Indexbasierten von X/Y nützlich
[20:25] MatthiasT_: zumindest habe ich die beim amforth schon mal so eingebaut, was mir nützlich zu sein scheint
[20:26] BerndPaysan: Das sehe ich auch so, ich habe entweder Anwendungen mit Increment oder welche mit Index.
[20:26] frunobulax: Beim Neuerfinden gibt mann A/B natuerlich alles mit was es so gibt.
[20:28] BerndPaysan: Bei einem richtigen analytischen Compiler sehe ich aber keine echten Vorteile gegenüber Locals (ohne Adresse, also iForth-Params)
[20:28] BerndPaysan: Und es gibt auch Fälle, bei denen zwei Register nicht reichen.
[20:28] BerndPaysan: Beispiel in meiner 3d-Turtle: Kreuzprodukt zweier Vektordifferenzen, braucht drei Pointer mit Indexoperation.
[20:29] MatthiasT_: A/B/C ? ;=)
[20:29] frunobulax: Du hasst ja richtig snelle Reflexen und ein sehr schnelles LCD 
[20:30] BerndPaysan: Ja, ich habe das dann natürlich mit Locals gelöst.
[20:30] BerndPaysan: Bzw. gleich in Assembler geschrieben ;-).
[20:35] frunobulax: Bernd: Ich verstehe eigentlich nicht wie es moeglich ist das iForth32 Windows mit dem A/B test langsamer ist als unter Linux. Soviel Einfluss kann das OS doch nicht haben?
[20:36] BerndPaysan: Je nachdem, wie sich verschiedene Pointer im Cache beharken, weil das OS das Page coloring falsch gemacht hat...
[20:36] michael_ hat den Chatroom betreten.
[20:36] BerndPaysan: Zumindest auf dem Pentium 4 kann ich mir da sehr viele Fehlerquellen vorstellen.
[20:36] BerndPaysan: Hallo Michael!
[20:36] uho: Hallo Michael!
[20:36] MatthiasT_: Hallo Michael
[20:36] michael_: iss n bisschen spät geworden - hallo allerseits.
[20:38] michael_: Um was gehts gerade - oder seid ihr schon beim verabschieden?
[20:38] BerndPaysan: Wir reden mal wieder über A/B X/Y.
[20:38] michael_: ah, ja. hab davon gehört von Matthias.
[20:39] michael_: das log kann ich dann ja nachlesen nachher.
[20:41] michael_: müde?
[20:42] michael_: oder schon ausgequatscht allerseits? 
[20:42] BerndPaysan: Ich glaube, wir sind mit dem A/B-Thema durch.
[20:42] michael_: aha.
[20:43] michael_: mein mittwochtermin (Tango) is nicht mehr. Ich werd mal versuchen hier öfter wieder rein zu schauen.#
[20:44] michael_: ab 20:00 könnte ich. Ihr fangt wann an derzeit?
[20:44] uho: Ja, 20:00 Uhr bis 20:15
[20:45] michael_: ok, dann bin ich ja noch nicht sooo spät dran, oder?
[20:45] uho: Hast Du es hinbekommen Jonesforth PPC zu übersetzen?
[20:45] michael_: nee, hatte bis gerade patienten. Das kommt später heute dran - hoffe ich.
[20:46] frunobulax: Wie interessant waere tForth heute? Wird SeaForth durchbrechen?
[20:47] michael_: Forth-Chat IRC #forth-ev - wie kann man die Nachricht als Dauermeldung in den Terminen des forth-ev weblog halten?
[20:48] uho: Was konnte man in tForth machen? Ein interaktives Forth mit Interpretern auf allen Transputern?
[20:48] BerndPaysan: Kann man die Termine nicht wöchentlich wiederholen?
[20:49] frunobulax: Das ist es jetzt (oder war es bevor Albert es betreuten).
[20:50] michael_: Bernd: ich sehe gerade, Termine lassen sich kopieren. Dann könnte ich das ja mal übernehmen da ne serie vor zu sehen.
[20:51] BerndPaysan: Ja, aber eine richtige Wiederholung wäre mir lieber - geht aber, wie ich sehe, nicht.
[20:52] BerndPaysan: Ich will ja in der Übersicht immer nur den nächsten Forth-IRC-Termin sehen, und das ohne wöchentliches manuelles Eingreifen.
[20:52] michael_: gibt es eigentlich forth auf grafikkarten? die dinger haben ja viele parallele prozessoren und massig ram.
[20:52] BerndPaysan: Evtl. einen Feature-Request beim Geeklog wert.
[20:53] BerndPaysan: Und seit kurzem gibt's zumindest für ATI-Grakas auch genügend Doku, um das zu implementieren.
[20:53] michael_: bernd:  voraustermine können ein erscheinungsdatum kriegen und ein verfallsdatum. is aber handarbeit.
[20:54] BerndPaysan: Eben, ich will, dass Computer Dinge automatisch erledigen, die man nach einfachen Regeln berechnen kann.
[20:54] michael_: is was für ne stille stunde, dann hat man da ne längere zeit die termine stehen.
[20:55] uho: @bernd: meinst Du CUDA?
[20:55] michael_: viel C für die grakas gibts ja schon hörte ich.
[20:56] BerndPaysan: CUDA ist die C-Implementierung, ich meine die Doku zu den R500/R600/R700-Prozessoren, die man bei X.org findet.
[20:56] BerndPaysan: Da kann man wirklich direkt auf der Hardware loslegen, ohne Abstraktionsschicht.
[20:57] uho: aha - bare metal
[20:57] michael_: adolf sprach von CUDA am Montag - er war ganz erstaunt was da abgeht inzwischen.
[20:58] MatthiasT_: Mit Graks werden inzwischen die WLAN Encryption Keys geknackt
[21:01] michael_: was meint eigentlich: Compute Unified Device Architecture (CUDA)?
[21:01] BerndPaysan: CUDA und das AMD-Konkurrenzprodukt CTM soll ja von OpenCL abgelöst werden
[21:01] BerndPaysan: (Apple-Idee)
[21:03] uho: OpenCL (aus der OpenGL-Schmiede) soll ja erste mit der nächsten Mac-OS X-Version kommen. Vielleicht gibt es ja eher Previews.
[21:06] frunobulax hat den Chatroom verlassen. (Uni-Erlangen.DE BelWue.DE)
[21:06] BerndPaysan hat den Chatroom verlassen. (Uni-Erlangen.DE BelWue.DE)
[21:06] uho: Na, das ist Erlangen wohl abgeklemmt worden.
[21:07] uho: Das Jonesforth ist ja ganz nett, wegen der vielen Erklärungen im Quelltext.
[21:07] uho: Aber es weicht ganz schön von unserem Forth ab.
[21:08] uho: Flags sind 0 und 1 (nicht -1)
[21:08] uho: immediate ist immediate
[21:08] uho: here ist eine Variable (DP)
[21:09] frunobulax hat den Chatroom betreten.
[21:09] BerndPaysan hat den Chatroom betreten.
[21:09] BerndPaysan wurde von BelWue.DE zum Operator gemacht.
[21:09] uho: WORD hat den Stack-Effekt  ( -- c-addr len)
[21:09] uho: kein DOES>
[21:09] uho: usw usw.
[21:09] BerndPaysan: Ich habe hier dank Netsplit wohl nicht alles mitgekriegt in den letzten Minuten.
[21:09] uho: Aber, als Grundlage für ein Modell-Forth vielleicht ganz gut.
[21:10] uho: Das Log müssen wir dann zusammenmergen, oder wir nehmen gleich meins.
[21:10] BerndPaysan: Ok, nehmen wir deins.
[21:10] uho: Ich überlege, ob NASM eigentliche eine gute Plattform für so ein Modell-Forth als Assembler-Listing wäre.
[21:11] uho: Oder gibt es einen Portablen auch noch Cross-Target-Assembler?
[21:12] MatthiasT_: word (-- c-addr len) könnte mir gefallen ;=)
[21:12] uho: Ohne den Delimiter als Argument?
[21:13] BerndPaysan: Der Delimiter für WORD ist eigentlich immer BL.
[21:13] BerndPaysan: PARSE wird für Parsing mit anderen Delimiter verwendet.
[21:13] MatthiasT_: ok, ich hatte mehr das Ergebnis im Blick. Asche auf mein Haupt
[21:13] MatthiasT_: Aber vielleicht schafft das ja forth 20xx 8=)
[21:13] BerndPaysan: Deshalb gibt's bei Forth200x ja PARSE-NAME.
[21:13] BerndPaysan: ( -- c-addr len )
[21:13] uho: Hast Du Recht Bernd, aber in Standard ist das eben anders.
[21:14] uho: Und eine Modell-Forth soll eben erklären, wie man den Standard implementieren könnte.
[21:15] BerndPaysan: Ja, da muss man das natürlich dann umbenennen, also eben PARSE-NAME nennen (das ist ja Bestandteil von Forth200x)
[21:15] uho: yep-
[21:15] BerndPaysan: WORD gehört dann natürlich schrittweise obsolescent gemacht.
[21:16] michael_: standard geht aber nicht auf multi parallel prozessing?
[21:16] uho: haeh?
[21:16] michael_: na, diesen grakas.
[21:17] uho: wieso soll da kein Standard Forth laufen sollen?
[21:17] michael_: ja ist denn geklärt wie forth parallelisiert werden könnte?
[21:18] uho: das ist ja außerhalb des Standards
[21:18] michael_: die VM war ja doch als einfacher prozessor gedacht.
[21:18] michael_: konnte ja sogar ich verstehen 
[21:18] uho: Communicating Sequential Processes
[21:19] BerndPaysan: Ein Forth-Programm läuft auf einem Prozessor.
[21:19] BerndPaysan: Und die Kommunikation kann man je nach System so oder anders implementieren.
[21:19] BerndPaysan: SeaForth hat halt Quellen und Ziele links/oben/rechts/unten (und bei den Zielen auch kombiniert).
[21:20] michael_: da hats noch keine allgemeiner bewährten Modelle?
[21:20] BerndPaysan: Antons Vorschlag, einfach Pipes zu deklarieren, und Filter-Ketten zusammenbauen, abstrahiert das.
[21:20] BerndPaysan: Ist aber eben "nur" ein Vorschlag, noch nicht implementiert.
[21:20] michael_: Hat nicht Fred darüber geforscht?
[21:22] MatthiasT_: Gibt einen Link zu dem Vorschlag?
[21:22] uho: Ja oder eben tForth s.o.
[21:23] frunobulax: Transputer, tForth und iForth benutzen CSP. Hanno Schwalm benutz iForth fuer seine DSP sachen (SW radio).
[21:23] michael_:  Tony Hoare an der Universität Oxford entwickelte Prozessalgebra zur Beschreibung von Interaktion zwischen kommunizierenden Prozessen. (wikipedia)
[21:24] uho: Communicating Sequential Processes, s.o.
[21:24] michael_: klar , deshalb konnte ichs ja finden - danke für den tip  
[21:25] uho: Ist die theoretische Grundlage der Transputer und von Occam
[21:26] uho: Parallele Systeme werden als Systeme von Sequentiellen Prozessen aufgefasst, die miteinander kommunizieren.
[21:26] uho: Ein geniales Konzept.
[21:26] michael_: ich lernte soeben:  Hoares Buch war 2003 nach CiteSeer bereits das dritthäufigst zitierte Werk der Informatik.
[21:27] MatthiasT_: ich verlasse euch jetzt, bis neulich dann
[21:27] MatthiasT_ hat den Chatroom verlassen. (EOF From client)
[21:28] michael_: das war schnell, konnte man ja nicht mal tschüs sagen.
[21:28] michael_: und CUDA baut auf Hoare auf?
[21:29] uho: Ich kann mir gut vorstellen, dass man ein verteiltes/paralleles Forth eben auf CSP aufbaut (haben Fred und Albert und Marcel vielleicht ja schon gemacht, wenn sie Occam als Vorlage genommen haben....).
[21:30] michael_: na dazu würd ich ja gerne mal was in der VD lesen.
[21:31] michael_: hast du eine draht zu denen?
[21:31] uho: Marcel liest mit  Zu Fred habe ich einen Draht....
[21:32] michael_: frunobulax ist marcel?
[21:32] frunobulax: Ja, hier.
[21:34] michael_: ok. Hättest du nicht Lust zu so einem Beitrag?
[21:35] frunobulax: Es ist besser Hanno Schwalm zu fragen. Er baut ja richtig schwere Applikationen damit (wie sein Jack audio interface).
[21:36] uho: Fänd ich auch gut. Von Hanno habe ich ja lange nichts gehört.
[21:37] michael_: da wäre ein Interview nicht schlecht. Ob er hier mal reinschauen könnte?
[21:37] uho: Wer kennt ihn näher und mag mal nach einem Artikel fragen?
[21:39] michael_: mail schicken mit auszug aus dem hier gesagten und sehen ob er mal herkommt?
[21:39] uho: Ja - das ist ja ein Ansatz.
[21:42] michael_: ich sehe gerade: Elektronische Version des Originalbuchs zu CSP von Tony Hoare (wikipedia zu csp)
[21:42] uho: Ja - das ist online - aber kein leichter Stoff!
[21:43] michael_: dem hanno mailen, könntest du das machen Ulli?
[21:43] uho: Aber erst am Wochende
[21:44] michael_: Prima. Bin gespannt was passiert.
[21:44] michael_: so viel stoff für mich heute - das gibt ja noch ne lange lesenacht 
[21:45] michael_: Gute Nacht Freunde, es wir Zeit für mich zu gehn...
[21:45] BerndPaysan: Gute Nacht.
[21:45] uho: Genau - es wird langsam spät.
[21:46] frunobulax: Bye
[21:46] BerndPaysan: Bye
[21:46] michael_: bye
[21:46] frunobulax hat den Chatroom verlassen. ("a quit that really quits")
[21:52] michael_ hat den Chatroom verlassen.