FORTH 1: (was Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs

Ja wie in jeder Skriptsprache halt. Dass du das so besonders findest, wundert mich.

Ist halt meine persönliche Präferenz, dass ich etwas so hinschreibe wie ich es denke nämlich "eins plus eins" statt "eins eins plus".

Ich habe LLVM schon für den 6802 retargetiert. Auch etwa 1-3 Tage, würde ich sagen. Ist überhaupt kein Problem und kann dann, im übrigen, nicht nur C sondern eben auch alle anderen Programmiersprachen, die llvm beherrscht (C++, go, Haskell, Fortran, Rust, Javascript, Ruby, C# um nur einige zu nennen). Hätteste gar nicht gedacht, was? Liegt evtl daran dass 30 Jahre Programmiersprachenentwicklung scheinbar spurlos an dir vorübergegangen sind.

C ist extrem portabel, das gilt aber für alle Sprachen, solange nur den Standard-Sprachumfang verwendest. Ziemlich unglaublich, dass du das nicht verstehst. Ich weiß auch nicht, wie ich's dir noch besser erklären kann.

Das ist ja schön für dich. Schreib mal wie viele CPUs, die du kennst, für die es keinen C compiler gibt.

Der "blöde Trip" ist eine objektive Messung, die du jederzeit nachprüfen oder entkräften könntest.

Nein.

Deine groben zusammengelogenen Faustformeln interessiert kein Mensch. Mach Messungen und publiziere Ergebnisse, dein Gelaber ist echt überflüssig.

So und jetzt belegst du das mal. Compiliere doch mal den RC4 für FORTH und sag wie viel der braucht. Stattdessen schwadronierst du nur rum, kriegst es aber nicht gebacken auch nur EINE belegte Zahl zu nennen.

Noch mehr dahergefibertes Gelaber. Ich habe gemessen: C = 1, Forth =

Ich habe nie behauptet, dass jemand, der Forth verwendet, ein Nichtskönner ist. Das hast du dir zusammengefibert. Ich habe lediglich demonstriert und objektiv belegt, dass Forth deutlich langsamer (Faktor

Gruß, Johannes

Aaaaaaaaahahahahaha! BWAHAHAHAHAHAHA!

Respekt, Respekt, du bist ja ein echter Spezialexperte.

Glaub es mir einfach!!!1111elf

Aaaaaaaaah ja klar, der NDA hindert dich daran, ein Hello World

Das kommt ja wohl aufs Target an. Du erzeugst Bytecode und der wird

Bytecode von Interpretation.

Na dann faktenchecken wir doch mal deine Behauptungen. Der RTX2000 ist

ISR auch wieder verlassen, da geht deine letzte Instruktion hin.

FORTH halt nun mal ohne Spezialhardware (Forth im Core) langsam ist, deutlich langsamer sogar manchmal (Faktor 500...) als C.

Niemand bei Verstand erwartet etwas anderes. Nur du tust so, als ob Forth die eierlegende Wollmichsau ist. In der Gruppe hier sind quasi nur Ingenieure. Die durchschauen dein Zelotentum ALLE.

gibt halt intellektuell grundlegend unehrliche Leute wie du, die einfach Fakten wegignorieren, die ihnen nicht passen.

Joa das war ja auch meine Aussage. Zitat "irgendwelchen Spezialanwendungen Hardware gebaut wurde, die das performant interpretiert".

Nur ist die Welt halt nicht so: Alle modernen Prozessoren sind eben

sich durchaus weiterentwickelt. Dann hat man halt auch mehr Auswahl an Hardware als nur n Paar obskure Spezialprozessoren.

Was soll denn ein "C Kern" sein? Hast du auch nur die leisteste Ahnung

mal retargetiert, ja, und der kann dann u.a. C kompilieren. Ist nicht

die weder "zukaufen" muss noch selber machen.

einen C Compiler gibt, ohne dass man was erstellen muss?

Johannes

Wolfgang

-- Ich bin in Paraguay lebender Trollallergiker :) reply Adresse gesetzt!

ihr Niveau herunter und schlagen mich dort mit ihrer Erfahrung! :p (lt. alter usenet Weisheit) iPod, iPhone, iPad, iTunes, iRak, iDiot

Dummbatz.

nicht... wg. NDA sabbelst Du was von Hello World und Geschwurbel?

Nein, ist Eigenheit von Forth

Und Forth hat zwei Interpreter, den inner und den outer interpreter. Der

nennen, obwohl das bei FORTH noch wal wieder was ganz anderes ist.

Wenn ich das noch richtig im Kopf habe, macht der RTX den 'RETI' ohne

Au, jetzt legste aber dreist zu. Ich les noch ein bischen, aber...

einzelne Seele in 1-3 Tagen.

Nochmal ...leck mich und hasta la vista

Wolfgang

Ja, dachte ich mir schon. Jetzt wisch dir deine dicken Krokodilstränen aus den Augen und mach dich nicht doch nicht weiter zum Brot. Und die nächste Diskussion, die du vom Zaun brichst, führst du vielleicht mit objektiv belegbaren Fakten, deine Anekdoten und "gefühlten" Werte sind weder interessant noch relevant.

Du laberst und laberst und laberst und laberst, aber kriegst es nicht gebacken, ein WINZIGES Programm zu testen und die objektive Messung, dass der Forth-Code Faktor 500 mal langsamer ist, zu entkräften. Stattdessen kriegst du einen cholerischen Fiberanfall und schlägst wild um dich. Du warst bestimmt auch schon immer jemand, der bei "Mensch ärgere dich nicht" mit einem Armwisch das komplette Brett abgeräumt hat, sobald ein eigenes Männchen geschlagen wurde.

Und nochmal für dich zusammenfassend:

Niemand hat bestritten dass FORTH auf Spezialhardware (z.B. RTX20xx) effizient ausführen kann. Niemand hat bestritten, dass eine Sprache wie FORTH (oder ADA, etc.) für Spezialanwendungen (Raumfahrt/Safety) geeigent sein kann. Niemand hat bestritten, dass es Leute gibt, die RPN hübsch finden oder dass ein interaktiver Interpreter komfortabel zu bedienen ist.

Das EINZIGE Argument war, dass FORTH auf einer 08/15 Architektur (z.B. x86_64) eben etwa fünfhundertmal langsamer ist, als C-Code, der dasselbe tut. Und das Argument war dir sogar extensiv belegt worden.

Und nichtmal damit kommst du klar und interpretierst jegliche objektive Kritik als persönlichen Angriff. Meine Güte bin ich froh dass ich mit einem so unsachlich argumentierenden, hochnotpeinlichen Choleriker nicht zusammenarbeiten muss.

Gute Besserung und alles Liebe, Dein Johannes

Johannes Bauer snipped-for-privacy@gmx.de:

Eure Stilfragen beiseite, sei festgehalten, dass die obige Prozedur nicht korrekt ist.

Wenn einer die Farbe x als miserabel betrachtet, ein Chamäloeon mit der Farbe x sieht und dann herumposaunt, Chamäleons sind miserabel, dann hat er selbst auch miserablen Stil zelebriert. Wahrscheinlich, weil der Blick nur bis vor die eigenen Fúße reicht.

Wenn ich nun selbst nur einen Funken Interesse hätte, was was ich aber nicht habe, daran, was da als GForth im Umlauf ist und offenbar den Ruf schädigt, könnte ich vielleicht auseinanderklauben, was da schiwf gewickelt ist. Diese Maschine bezog ihren Anspruch auf Universalität zuzeiten daraus, dass stets ein C-Compiler irgendwo mitlief, das scheint immer noch so zu sein. Offenbar sehr zu ungunsten der Resultate. Akademische Spielkiste.

Der Unterschied: Subroutinen in Forth verbrauchen wenig Overhead, indem keine Frames eingerichtet werden müssen. Wenn aber ein anderer Conpiler fúr jede Forth-Routine (Forth-Wort) einen neuen Stackframe einrichtet, dann ist die Brauchbarkeit ziemlich im Eimer.

Ein anderes Forth wäre das Open-Boot, wahrscheinlich auf dem Rechner, auf dem dies hier gelesen wird, und wenn man vom BIOS hochfährt, läuft dort ebendieser Token-basierte Forthdialekt als Maschinenmonitor, für den Zugriff auf den Hardware-Bus und die Devices des Rechners.

Aber ach, wenn man ständig Heiuweh nach dem Massenkungeln im Mainstream hat, darf der eigentlich kindlichen Bindung an ein ewiges ozeanisches Wogen gern der Rest der Welt als entweder bedrohlich oder verabscheuungswert vorkommen.

Kannma schon. Wenn es nur darum geht, muss man das nicht weiter ernstnehmen.

Hmm, naja wie gesagt, wenn es etwas besseres gibt auf FORTH-Seite, dann würde ich das auch gerne ausprobieren. Kennst du eine Alternative? Ich kenne mich, wiegesagt da einfach nicht aus. Hätte jetzt auch vermutet, dass der Overhead schon geringer sein kann (mein Bauchgefühl sagt Faktor

Die Beweislast liegt üblicherweise bei demjenigen, der die Behauptung aufstellt. Wenn der aber keine Aussage machen kann oder will, dann muss er sich nicht wundern wenn ein Fachfremder Messungen macht, die halt (aus purem Unwissen heraus) nicht das Optimum herauskitzeln aus der Implementierung.

Hmm, verstehe ich nicht. Du meinst die übersetzen von Forth nach C und von C nach Assembler und führen das dann aus? Aber wäre das dann nicht nur einmaliger Overhead und würde eben mit längerer Ausführungszeit vernachlässigbar sein?

Das ist ein interessantes Argument, das ich schonmal bei Rafael gehört habe, aber das sich mir nicht wirklich erschließt. Also konkret gefragt: Welcher Overhead wird wo gespart? Und gilt das dann nur bei Unterroutinenaufrufen? Da wird in der Regel bei einem modernen, guten C Compiler auch kein Stackframe erzeugt, wenn das nicht notwendig ist.

Auf dem kann ich aber nicht testen :-)

Hm, ne, darum geht's nicht. Allgemein sind das keine Kategorien ("bedrohlich" etc.) in den ein vernünfigtiger Techniker denken sollte. Eine Technologie (z.B. Programmiersprache) hat Vorteile und Nachteile. Es ist gemeinhin klar, dass *alles* ein Kompromiss darstellt. Entwicklungskosten, Laufzeitkosten, Hardwareabhängigkeit, Verfügbarkeit der Werkzeuge und Hardware, Gehalt der Ingenieure die man braucht, usw usf. Das gilt ganz allgemein.

Wenn sich jetzt einer hinstellt und sagt, Technologie X ist in ALLEN Aspekten der Technologie Y überlegen, dann ist das halt Quatsch und das ärgert mich. Es kommt halt auf den Anwendungsfall an, was jeweils besser geeignet ist. Mir sind die Nachteile von C durchaus bewußt, aber ich nehme sie halt in Kauf, weil ich im Embedded-Bereich meistens eben damit insgesamt noch am besten fahre.

Viele Grüße, Johannes

Nun ja, Forth ist eher schon eine Lebensanschauung und der bin ich in weiten

bei Desktopzeugs einfach bessere Karten. Aber zu Zeiten, als ich auch noch die Stringroutinen des awk je nach Bedarf in Forth nachgestellt habe, ging das so, dass der Mensch eben mit seinem Werkzeug zienlich eng verwachsen

z.B. Primzahlen rechnen lassen, das ging dann mehr und mehr in Assembler.

Secondaries stehen (also in Forth-Worten, die aus Tokens bestehen).

Output eines Compilers konsumiert als wie eine Service-Leistung.

Ebene ist das auch eher die Vorstellung von ihrem Zielpublikum, siehe die

Payware mit etwas Vorlaufzeit zum Evaluieren und Kennenlernen (und dann gibt es zumindest noch weitere Elaborate, etwa aus Southampton).

von kurzen Routinen, plus die Wirkung des Optimizers.

Derart langsam finde ich das auch inakzeptabel. Hatte einst eine Idee von Langsamkeit, als bei mir ein Forth-Interpreter, mit sehr wenig Assembler

Dunkel nebelt durch die Erinnerung ein Modell heran, wo ad hoc je ein Forth-Wort per C zu einer Sammlung von anderen kompiliert wurde, und dann eben brav die Maschine mit zwei Stacks auf der Maschine mit nur einem Stack

Laufzeitumgebung an die Parameter, die auf dem Forth-Stack liegen sollten, der aber erst einmal zu emulieren ist, wenn der eine Stack zugleich der

Wollte jetzt nicht die gefinkelten C-Compiler dagegenhalten.

Wenn man das nicht will, schreibt man mit Variablen (oder Local Values) und

ROT TUCK OVER usw.

Denkweise ist ein wenig anders als beim Algebra-fixierten Mainstream.

Andersherum, ein paar Variablen, dann werden die Parameter nicht mehr anonym auf dem Stack herumgeschoben, weil dann die Namen im Quelltext stehen.

Solange man aber mit dem Stack auskommt, ist vor allem einmal ein Vorteil, dass der Code nach Belieben reentrant ist, es also keine Nebenwirkungen bei

Local Values, aber die gehen dann in die Richtung, dass ein Frame bei Aufruf zwischengesichert werden und beim Verlassen wieder restauriert werden muss -

der Zwischenzeit, nicht mehr geschaut habe solches dann mehr).

Abarbeitung der Tokens eben keine andere Instanz, die quasi hinter dem

laufzeittechnisch.

weiterschaltet. Und das ist schnell: den reservierten IP inkrementieren,

reserviert, sonst wird der Ablauf wieder ineffizient. Landet man bei einer Token-Liste, dann wird der IP gesichert und umgeladen, und gleich mit NEXT wieder in der neuen Liste begonnen, auch das geht flott. Und all dies

ziemlich eisernes Regime, wie die Resourcen der CPU zu verbraten sind. Die beiden Stacks als SP, RP, den Instruction Pointer IP plus ein Umladeregister, eventuell dazu Top-Of-Stack in einem Register.

gestrickt, also von Assembler weg hochgezogen. Diese Denkweise ist auf den Desktops nun aber eher rar geworden, wenn man nicht in Richtung Redmond schaut, wo Intel mit sozusagen einbetonierter 80x86-Historie das Fahrwasser vorgibt.

lowlevel-Umgebung des Open-Boot im BIOS von Desktops.

Modell jedes kurze Forthwort ein eigenes C-Kompilat darstellen soll, hat der

weniger zu tun.

Zuletzt dass ich damit herumgetan hatte (also schon lange nicht mehr), waren bei meinem Leib- und Magen-Werkzeug die Optimierungen Forth-intern, d.h.,

darstellen lassen, wurden aufgefunden und zusammengefasst.

strikten One-Pass-Compilers. Es ist ja nicht traditionellerweise das Kompilat das Ziel, weswegen ein Quelltet geladen wird, sondern, abstrakter,

Passagen wiederauftaucht.

Man kann sich aber, seit dem ANS/ISO-Modell, mit den Mitteln zur Interpretersteuerung unterwegs gern seinen Mehr-Pass-Compiler stricken. Das

monokausal gestrickte Denkweise, wozu der Quelltext und wozu der Compiler

kann.

reloziierbaren Objektcode zu generieren, als externes Modul gesichert, um es ohne Quelltext ein andermal zu laden.

Aber aus der Arbeitsteilung, wie die Werkzeuge nun, wenige Jahrzehnte

Bei vielfach andersartiger Sichtweise muss das Ding ja nicht auf jedes

man mit dem Werkzeug umgeht, nicht auf dem Radar aufscheinen wird. Sprich,

der eigenen Ideen, noch bevor der geplagte Programmierer dann sein Werk beginnen will. Letzteres hat der Mainstream nicht vorgesehen. Die Welt bestehe aus Algorithmen und die schreibe man in Algebra.

Am 18.08.19 um 20:43 schrieb Ewald Pfau:

Keine Maschine, die (Rx++) und (--Ry) kann muss an Stacks Mangel leiden. Sagen wir alle nach der PDP-11.

Nein, das war mal relativ schnell zu 6502-Zeiten. Auf heutiger Hardware ist das der direkte Weg zum Untergang. Wenn man alle 5 Maschinen-instruktionen die Pipeline flusht, noch dazu mit unbekanntem Sprungziel, dann bleibt von einem Pentium allenfalls ein 8086 übrig.

Und ja, ich mal eine UCSD-Pcode-Maschine für den Z8000 geschrieben und auch eine für Andrew Tannenbaum's Free University Compiler Kit; das war OK für damals. Mit heutiger Hardware ist das sinnlos und völlig folgerichtig ausgestorben. (Und eine 16 bit Stackmaschine in Hardware in HP's dynamischen NMOS, das war eben der Zeitgeist, damals.)

Und die 500 Renaming-Register kann man auch wegwerfen, wenn sich das ganze Programm immer nur mit dem TopOfStack und den NextOnStack beschäftigt. Wenn schon ein Cache-Zugriff -zig Takte braucht und ein Hauptspeicherzugriff > 100.

Heutige Maschinen brauchen _Überblick_ damit sie mit der Hardware Parallelität herausfischen können. Tunnelsicht auf den TOS bringt einen da nicht weiter. Eine Instruktion pro Takt ist heute nichts mehr wert.

In aktuellen Intel-CPUs ist von 8086-Historie nichts mehr übrig. Das sind jetzt multiskalare RISCs mit Hunderten von Registern und spekulativer Ausführung. Einzig die Codierung der Instruktionsbündel riecht noch etwas streng nach X86. Das hat aber mit dem, was nach der Decodierung abgearbeit wird, absolut & überhaupt nichts mehr zu tun.

Gruß, Gerhard

Wie Spectre und Meltdown zeigen hat INTeL das mit der spekulativen Ausführung spektakulär verkackt. Zumindest mich wundert seitdem nicht mehr warum sie immer schneller als AMD waren. Wenn man an der Sicherheit spart ist es leichter schneller als die Konkurrenz zu sein.

Gerrit

Das ist völliger Blödsinn. Wer nichts macht, macht auch keine Fehler. An spekulativer Ausführung führt kein Weg vorbei. Und einige dieser Fehler waren auch im ARM, trotz völlig andere Mikroarchitektur.

Intel ist immer gleich der Prügelknabe.

Dabei ist der 86 gar nicht so link gewesen, wenn man erst mal eingesehen hat, dass die Segmentregister eine MMU sind und nix mit der CPU zu tun haben.

Aber, was hatten die $(ANDEREN) immer so tolle CPUs!!11elf!!

Da war der 32032 von National (startete als 16032) super-duper-symmetrisch, sogar Arrays in den Registern. Erstickt an seinen Bugs.

Micro-VAX. Hübsch, angenehm, lahm.

Die 68000-Familie. Ätsch, der x86 kann kein double-memory-indirekt-deferred. Wir schon. Bis sich dann gezeigt hat, dass es Instruktionen gibt die niemals terminieren, weil immer noch ein page fault / exeption/ wasauchimmer reinpasst. Beim 68060 war Schluss mit lustig. Nicht mehr zu verstehen. Auch nicht richtig schnell, irgendwie.

Z8000/Z80000. Kam nie in die Puschen.

Transputer. Ich hatte auch mal ein Cluster von 4 Stück. Das habe ich mal jemandem geliehen für'n Supercluster und nie zurückbekommen, war ehrlich gesagt auch nicht mehr sehr dahinter her.

Fairchild Clipper. War schon eine 3-Chip-Lösung. Kaputte Cachelines wurden mit dem Laser abgehängt zur Verbesserung der Ausbeute. Ein Programm ein paar Bytes rauf oder runterzuschieben konnte eine enge Schleife beschleunigen oder ganz erschröcklich verlangsamen. Blieb exotisch.

IBM Power PC. Ja, hatten wir embedded in einem Virtex. Es gab nie einen Nachfolger von Xilinx, von IBM irgendwie auch nicht.

DEC Alpha. Was gab das Tiraden in comp.arch, wie überlegen der war!

HP700 / Snakes / KingKobra War schnarch-langsam. Ich hab' noch so ein Teil unter HP-UX in einem Agilent 16702B-Logikanalyzer. War schon damals schlimm. Das HP-Nachfolgedesign haben sie geschaft Intel unterzuschieben. Taugte auch auf Intel's Prozess nix und war dann irgendwie Intel's Fehler.

SUN. Ja, die Sonne ist über dem Sparc untergegangen.

MIPS. Soll jetzt open source sein. Hat nicht gereicht. Ich fand sie eigentlich ganz angenehm.

Ja, der ARM hat's geschafft. Der hatte den Bonus, die wirklich allerletzte Alternative zu sein. Sammelt auch fleißig Komplexität.

Und AMD steht im Augenblick ganz gut da. Treuer Intel-Vasall seit dem 8080, abgesehen von dem Seitensprung mit dem Z8000.

Vermutlich habe ich den ein oder anderen Intel-Roadkill vergessen.

Gruß, Gerhard

Am 18.08.2019 um 21:57 schrieb Gerhard Hoffmann:

Sofern keiner der Stacks überlaufen kann.

Danke für die ausführliche Liste von Hardware-Optimierungen. Mir stellt sich da die Frage, was davon bei Steuerungsprogrammen besonders vorteilhaft auffallen könnte. Daß FORTH nichts für Numbercrunching ist, hatte ich ja schon angemerkt.

DoDi

• Gerhard Hoffmann snipped-for-privacy@arcor.de:

Der *war* überlegen.

Als der Alpha 21064 1992 rauskam - 64 Bit! 200 MHz! - zitterten der Konkurrenz die Knie. Intel machte damals noch 486er, Sun den SuperSPARC, IBM den Power1 für die RS/6000, alle mit max. etwa 50 MHz, und das waren alles 32-Bit-Chips.

Ein Doktorand von unserem Institut ging ca. '94 zu Intel und wurde ein, zwei Jahre später einer der Chef-Architekten des ersten IA-64-Chips, Merced. Nach seinen Erzählungen hatten sie damals bei Intel "vor niemandem Angst, ausser vor Alpha". Ein paar Jahre später machte DEC Pleite, Compaq war nicht an Prozessoren interessiert und die Alpha-Ingenieure gingen zu Hunderten zu Intel, HP oder AMD. 1999 meinte der Kollege: "Angst? Wir haben vor keinem mehr Angst".

DEC hat sicher viele Fehler gemacht, aber Alpha gehörte nicht dazu.

- Andi

Technisch sicher nicht, in der Vermarktung schon: Man stelle sich vor, wie es aussehen würde, wenn sie damals die Alpha-Architektur z.B. an AMD lizensiert hätten.

/ralph

Das war das zentrale Problem von DEC - lauter Ingenieure, die Null Ahnung vom Business hatten...

Und weiter: Es gibt 2 Arten der Geheimhaltung:

Es verging zu meinen DEC user Tagen, nicht ein Tag, wo ich in den meterlangen AKtenordnern zu PDP11, RSX11M, RT02, RT11, LSI11... DECUS

dort waren u.a. viele Gurus von DECUS. Internet gabs nicht, und Telefon reichte nicht. Haben uns auch gegenseitig HW und SW (jau, die lustigen

Und um wieder OT zu werden :)

Anlage ging. Jeder zeigte auf den anderen und ich sass in der Patsche bei

interaktiv die Sache erfolgreich debugged und hatte am Ende eine gute Sammlung von Test 'Worten' in FORTH, die dann von unseren Serviceleuten,

Doku, die sich auf dem Controller durch eine aufgekratzte Leiterbahn, eine

waren und absolut nix lief. Die HW Lieblinge der GL fielen nicht in

Ich hatte gerade Berichte von Mitch Bradley (SUN) gelesen, wo er

neue CPU (die er einfach mit FORTH emuliert hat) fertiggestellt hatte. Er

sein, dass der Controller im Plan lag, wo doch die CPU noch garnicht

der spinnt, der Hardwarenix!

Als dann die CPU lief und der Controller samt HDD und Treiber auf Anhieb auch, war grosses Theater im Management. Mitch musste dann tausendmal

das Open-Boot (s.h. ebenda) und von da an gabs Open-Boot auf allen SUN.

interessiert und Dein Labor dauernd voller Fremder ist :)

auf die 2 Stack Architektur von FORTH verzichtete, ist (mir)

Andere Berichte sagten, dass FORTH Programmierer 3-30x produktiver als in allen anderen Programmiersprachen sind. Wenn das stimmte, dann sah ich da meine einzige Chance. Ich erinnerte mich an meine Erfahrungen, hab dann mich und 2 weitere Ings verschworen, es mit FORTH zu probieren. Wenige Tage vor dem Projektstart, war ich mit 3 meiner MA auf einem DEC

Ich engagierte Flesch Forth Systeme um uns auf den Pott zu bringen und 3 Wochen zu pampern, bis wir mit dem LMI Forth samt Metacompiler alleine weiter arbeiten konnten. Wir benutzen 3 Mostek Z80 Entwicklungssysteme die an unserer PDP11/34 per CL (20mA 9600Bd) hingen. Ein Flesch Mann war immer zugegen um als wandelndes Lexicon und Bezaubernde Jeannie (ok, Barbara Eden war sexier :) auf Fingerschnipp zu helfen.

Projekt hab ich dann noch von dem zu klein werdenden Z80 auf 64180 umgestellt, die beiden anderen haben nichts bemerkt, ausser dass alles

mitten im Projekt auch noch die Pferde gewechselt (z80 -> 64180) Ich war erstaunt, was Wut (auf die GL) an Energien und Motivation (auch bei den anderen Beiden) freisetzen konnte.

Aber statt Lob aus der GL kam nur: Siehste, man muss die Softies nur ordentlich treten, dann klappt das auch!

mitbekamen (und noch ein weiterer), wollten sie mit mir gehen.

ordentlich Projekte von dem alten AG mitbekommen. War ne prima Starthilfe.

Der einzige Fehler war, dass wir alle 4 gleichberechtige Partner waren.

Hat mich meine Einlage von 20.000DM gekostet und den 924S hat dann einer

und dann an einen Zahnarzt weiterverkauft) :o

Ein jap. Sprichwort sagt: Wer von der Hoffnung lebt, wird wenigstens nicht dick!

Hat bei mir gefunzt, nur noch FORTH und embedded HW+SW, ordentlich an Umfang (nicht nur Bankkonto) zugelegt :) und mich und meine Frau und meine

finanziert.

inzwischen in Rente gegangen.

Wolfgang

Am 19.08.2019 um 14:11 schrieb Wolfgang Allinger:

Es freut mich für Dich, daß Du mit dieser Sprache so erfolgreich warst, ich konnte ihr nie was abgewinnen und RPN finde ich schlichtweg abartig.

Das war ein Kompromiß, der von den Grenzen der Technik erzwungen wurde, als Taschenrechner selbst für meinen Vater noch zu teuer waren. Ich bin nicht mit HP sondern, für auch noch fast 1000 DM, mit dem TI58 eingestiegen und später einem gebrauchten TI59. Es mag sein, daß man lernen kann, wie eine Maschine zu denken, und sich dann damit wohlfühlt. Ich wollte das nicht. Längere Formeln fehlerfrei vom Papier abzutippen war auch so schon schwer und fehlerträchtig genug.

Die polnische Notation selbst, +(3,4) statt 3+4, hat was.

Tja, ich fahre heute auch nicht mehr mit der Kutsche ins Amt.

ich würde mir das heute freiwillig nicht antun wollen.

Stellt sich nur die Frage, was?