Kein Schwein programmiert(e) in Forth

Es gibt im Wesentlichen zwei verschiedene Paradigmen der Betrachtung von maschineller Datenverarbeitung. Das übeliche ist eine Maschine, die wie die staatliche Verwaltung funktioniert, sie wird mit Daten gefüttert und produziert handlungsanweisenden Output für Geräte und Leute, die von der Materie keine Ahnung haben.

Dagegen steht das physikalisch-biologistische Paradigma, eine Gruppe von Automaten, die durch einen Datenurwald turnt und dabei sowohl eine Spur geordneter Daten wie auch eine Verbesserung ihrer eigenen Existenzgrundlage produziert.

Die umgekehrte polnische Notation simplifziert die Dinge dadurch, dass das Funktionsmodell den Programmierer zwingt alle Daten herbeizuschaffen und geordnet bereitzulegen, bevor eine Funktion zur Ausführung kommt.

Dieser Programmierstil beseitigt die Notwendigkeit, für alles und jedes erstmal einen Namen zu erfinden, obwohl das Datum nur oder zweimal verwendet wird.

Auf der anderen Seite verunmöglicht die Nichtverwendung von Namen für nicht dauerhaft benötigte Funktionen und Variablen in Programmen die Erkennung das Denkmodells dahinter.

Wegen der Monopolisierung alles und jedes Programmiermodells bis herunter zu Einzeilern im hyperkapitalistischen Politikmodell sind auch alle anderen Programmentwickler auf kryptische Zeichenketten als Bezeichner umgestiegen.

FORTH, Mathematica und andere vereinfachen diesen Ansatz in das Extrem, dass das assemblierte Programm oder ein Hash davon selbst als sein Aufrufname dienen kann und wenn ad hoc als anonyme Daten oder Programme auf dem Stack eingesetzt nach Ausführung automatisch verschwinden.

Zufällig gestern in Wikipedia nachgeschlagen, die Vorgehensweise der kompletten Isolation der BIOS-Entwickler von der Produktionsabteilung und dieser vom Rest der Welt bei Phoenix zur Vermeidung von Patentrechtsstreitigkeiten mit IBM etc in den 1980ern:

So ist es. Der HP35 war einfach genial. Und dann die programmierbaren HPs erst.

Meist lernt man das Programmieren an dem, was da ist oder was man bekommen kann. Fortran-Kurs an der Uni, aber man kommt nicht an die Maschine. Teletype an der Uni, natürlich mit Basic. Dann die HPs. Endlich der Commodore Pet. Dann der Olivetti M24. Und der Pentium mit 90 MHz :-). Etc. Die Software war damals ziemlich teuer, und so nutzte man eben das, was mit dem OS mitkam. Wenn man einmal da eingestiegen war, wollte man natürlich nicht mehr "mal eben" das Pferd wechseln. Nicht umsonst war MS$ den Schulen gegenüber so grosszügig. Fast wie mit Drogen. Leider kam Linux viel zu spät. Man wollte ja MIT dem System arbeiten, und nicht nur DARAN.

Grüße, H.

Hilfreich für Obfuscation ist hier die Verwendung von lambda, möglichst geschachtelt ;-)

Das stimmt natürlich, aber wenn man gar keine Hits findet, ist es schon so ein Indiz dass man sich entweder vertippt hat, falsch errinert, ewig her war oder verboten ist :)

Perfekt, vielen Dank!

Die Fußnote, die ich nachgeschlagen habe: "Fifteen Programmers, 400 Computers, 36000 Sensors and FORTH". D.h. schon vom Titel wird klar, dass Wolfgang um den Faktor 10 übertrieben hat mit den angeblichen 4000 Computern, aber sei's drum.

Interessant ist der Inhalt nämlich allemal, aber das ganze ist jetzt eben schon 35 Jahre her. Mit 8 PDP-11s und ~400 8086ern haben sie das System aufgebaut. Der Prototyp lief unter FORTRAN und Assembler und wurde wohl von der Forth-Variante in Performance geschlagen.

Sowas, genau sowas, finde ich superspannend. Weil intuitiv sollte man ja annehmen, dass die mindestens dieselbe Performance erreichen könnten, insbesondere da die auf Asm zurückgreifen können. Das Paper ist auch ehrlich und dokumentiert, warum das so war: "the prototype software developed under RSX fell far short of meeting the performance requirements in the system [...] At the 8086 level, the lack of full multi-tasking in the RMX environment led to both performance problems and excessively elaborate code [...]"

Das finde ich deswegen spannend, weil genau die Tatsache, also dass kooperatives Multitasking mit Coroutinen (so verstehe ich Forth zumindest) eben in den letzten Jahren "neu erfunden" wurde, nennt sich denn asynchrone Programmierung oder asyncio. Das war lange in den Programmierparadigmen der typischen Hochsprachen (Fortran/C/etc) gar nicht vorhanden, und ist dann über die Skriptsprachen jetzt mittlerweile wieder reingewandert in klassische Hochsprachen.

Der Grund: Viel höhere Performance verglichen mit klassischen leichtgewichtigen Threads. Fand ich auch schwer zu glauben, ehrlichgesagt (weil eigentlich müsste das auch ja derselbe Overhead sein), die Messungen lügen aber nicht und das wird von dem 1985er Paper ja auch festgestellt.

Daher habe ich ihn:

Aber ja, ich nehme an, das ist nicht mehr in Betrieb, würde mich sehr wundern wenn in Riad noch PDP-11s und 8086er im Rechenzentrum stehen.

Auch spannend. Klingt aber eben eher nach Spezialapplikationen, wie Wolfgang sie auch aufgezählt hat: Satelliten, Roboterarm vom Spaceshuttle, Waffensysteme.

Ist ja auch nicht schlimm, für jeden Topf gibts ja einen Deckel. Aber so zu tun als sei Forth das, was heute noch federführend für Embedded-Applikationen eingesetzt wird, ist einfach unwahr.

Bist du dir wirklich sicher, auf dem i7, dass das Forth war? Es gibt ja die UEFI-Varianten die einen Interpreter haben, der etwas ähnliches emuliert, aber die sind m.W.n. nicht in Forth implementiert (sondern geben dir nur eine interaktive "Shell", die so ähnlich aussieht). Aber ja, macht man immer mit Bekanntschaft, wenn beim Installieren des Bootloaders was schiefgegangen ist :D

Vielen Dank jedenfalls für die Referenzen und unaufgeregte Diskussion. Es geht ja auch gar nicht darum, wer wieviel wo hat, sondern ich finde eher die Frage spannend warum das besser war, in welches Aspekten und was man darauf lernen kann um z.B. gute Performance auch in anderen Systemen zu erreichen.

Viele Grüße, Johannes

Am 17.10.2019 um 09:34 schrieb Heinz Schmitz:

Dann hast Du wohl den ST verschlafen. Dazu gab es alles, was das Herz begehrt, als Shareware oder in der PD. IMO ein Grund für den Untergang, weil sich kein kommerzieller Anbieter dort halten konnte und so der ST totgeschwiegen wurde.

DoDi

• Wolfgang Allinger snipped-for-privacy@spambog.com:

Achwas. Ich weiss sehr genau, was UPN ist, und ich will anderes.

HP kam nicht UPN, weil das so supertoll ist, sondern weil der HP9100 zu limitiert war, um algebraisches Format zu können.

Der HP 9100A war ein programmierbarer Tischrechner mit "Tastencode"-Programmierung, der so ziemlich alles, was später in den HP-Taschenrechnern verbraten wurde, schon konnte. Und zwar 1968, ohne LED, ohne ICs (und damit ohne RAM und ROM im heutigen Sinn). Ohne HP

BTDT. War ganz lustig, die Gehirnwindungen so zu verdrehen, dass sie dem Rechner passten. Der HP 9100B, den wir am Gymnasium hatten, existiert noch, und ich habe ihn vor ein paar Jahren mal ausgeliehen, ein paar Kontakte gereinigt, spröde Gummiteile und Lämpchen ersetzt

-- funktionierte wie am ersten Tag.

Und nachher nie wieder UPN. Denn in der Zwischenzeit hat man begriffen, dass Computer leistungsfähig genug sind, dass sie sich den Gehirnwindungen der Menschen anpassen können und nicht umgekehrt. Beispielsweise macht ein typischer Compiler für höhere Programmiersprachen bei der Berechnung von algebraischen Ausdrücken genau das: er konvertiert algebraische Notation in Stack-Arithmetik. Er bildet Terme, wirft sie auf den Stack, bildet Summen der Top-of-Stack-Elemente usw.

- Andi

Am 17.10.2019 um 13:22 schrieb Andreas Karrer:

Und der Benutzer wundert sich, daß nicht das gewünschte Ergebnis herauskommt. Weil er keine Ahnung mehr von Numerik hat, falsche Datentypen verwendet, Über- und Unterläufe produziert, weil ja alles anscheinend so einfach ist.

DoDi

Am 17.10.2019 um 13:28 schrieb Hans-Peter Diettrich:

DoDi

Am 17.10.2019 um 13:28 schrieb Hans-Peter Diettrich:

Es war vermutlich schon ein Fehler vom Baum herab zu steigen... viel zu

Ein denkbar schlechtes Argument.

Du wirst ja wohl nicht allen Ernstes behaupten wollen, dass man das Abstraktionsniveau möglichst niedrig ansetzen sollte, damit man eine geringere Programmierfehlerquote erreicht? Ich vermute, exakt das Gegenteil ist der Fall. Denn Numerik, Datentypen, Über- und Unterläufe muss man auch in einer niedrigeren Abstraktion berücksichtigen. Aber obendrauf kommt dann halt noch krude, umständliche Syntax (z.B. direkt Assembler-Code oder RPN) die eben nicht direkt das widerspegelt, was ich machen will.

Beispiel:

y = a x^2 + bx + c

Sofort offensichtlich, was das ist.

#define sqr(x) ((x) * (x))

y = a * sqr(x) + b * x + c;

Und jetzt

mulsd %xmm0, %xmm1 mulsd %xmm0, %xmm1 mulsd %xmm2, %xmm0 addsd %xmm0, %xmm1 addsd %xmm3, %xmm1 movapd %xmm1, %xmm0

Oder eben

x x mul a mul b x mul c add add

(Das ich dreimal angeschaut habe um sicherzugehen, dass es stimmt)

Also ich persönlich bevorzuge die Repräsentation, die dem am nächsten ist, was tatsächlich mathematisch gemacht wird. Bei der man direkt erkennen kann, was passiert.

Gruß, Johannes

ACK :)

Danke für Deinen tollen Beitrag.

Saludos (an alle Vernünftigen, Rest sh. sig) Wolfgang

Und in FORTH lustige Stackturnereien, gewürzt mit ROT -ROT PICK n ROLL TUCK UNDER dazwischen noch R! R@ RDUP RSWAP RDROP.

Ich hab so erfolgreich mal EPROM Kopierer ausgebootet zusammen mit einem DALLAS Key in TO92 Gehäuse. Der war im Schaltplan und Stückliste als BC237 aufgeführt. Ich hab da die Kennung abgeschliffen. Heute würde ich sowas als SMD ohne Bezeichnung einbauen.

Der Kunde wollte die Entwicklung nicht bezahlen, sondern nur per (weiterverkaufter) Karte von mir. Er hat dann 1, danach 10 gekauft und dann kam nix mehr :o

Der Kunde hat dann die Boards schlau wie er war bei Phytec geordert, den BC237 eingelötet, EPROM kopiert ausgeliefert und sich über die sporadische Meldung 'EPROM-Fehler, CPU angehalten' "gewundert". Er hat dann wochenlang per LA, ICE und was weis ich nicht noch alles rumgedoktert, aber die Routine nicht gefunden und schon garnicht flachlegen können. Was für ein Pech! :)

Direkt nach dem RESET wurde der Key obfusciert eingelesen, ne 20 zeilige Stackturnerei damit gemacht, so umme 100 Werte auffem Stack hinterlassen und dann nach der kompletten HW Initialisierung wurde die richtige Info auf dem Stack umgerührt, rausgepuhlt (ich wusste ja, wo die steht), der Stack bereinigt, eine Zufallszahl erzeugt und in der 1ms Tickerroutine nach runterzählen der Zahl der R-Stack manipuliert und der EPROM Fehler angezeigt oder auch mal gnädig zufällig übergangen. :)

Ich hab dann den Auftrag bekommen, 20(?) seiner Boards gegen flockige Kohle zu ertüchtigen und dann hat nur noch bei mir bestellt. Endkunde war wohl BMW und Audi, die werden ihm mächtig Druck gemacht haben.

Man sieht, es gibt Schweine als Kunden und noch grössere Schweine als Entwickler :)

Wenn das noch nicht genug ist, dann kann man auch Worte umtaufen.

Saludos (an alle Vernünftigen, Rest sh. sig) Wolfgang

Am 17.10.2019 um 14:21 schrieb Johannes Bauer:

Ach so, Du verwendest auch noch einen Interpreter, der sich um die richtigen Datentypen kümmert - so gut er das eben kann?

Vermutlich hast Du dann auch noch nicht verstanden, daß es neben den tatsächlichen Programmierfehlern auch noch Fehler in der Numerik gibt, die zu unerwartet falschen oder unterschiedlichen Ergebnissen führen, je nachdem welchen Compiler und Optimierungslevel man benutzt.

Von wegen umständlich siehe unten :-]

Inklusive der vergessenen Operatoren :-( Oder soll bx eine weitere Variable sein? :-]

Das ist doch genau das was ich oben meinte, mit schlampigem Denken und schlampiger Schreibweise, was zu schlampigen Programmen führt :-(

Und das ist eindeutig UPN. Woher soll man denn vorher wissen, welche der von mir aufgezählten Varianten Dein Lieblingscompiler erzeugt? Und was mathematisch eindeutig aussieht, muß nicht unbedingt eindeutig sein. Die Mathematik kennt Kommutativität und Assoziativität, die mathematisch immer identische Ergebnisse liefern, numerisch aber dummerweise nicht.

Das ist was anderes, da kommt Gewohnheit ins Spiel. Und in diesem Beitrag erkenne ich etliche schlechte Gewohnheiten :-(

DoDi

Ist das die erste mathematische Formel, die du in deinem Leben siehst? Muss ich dir jetzt echt Nachhilfe in Sechtsklassmathe geben? Ohje, bei dir fehlt's aber wirklich an Einigem.

Sage das doch den Mathematikern der Welt. Die verstehen, was ich meine. Ich vermute stark, du stellst dich einfach nur dümmer als du bist (sonst wäre das schon hochgradig bedenklich).

Wundert mich nicht.

Calling convention nachsehen, wenn du schlau werden willst.

Wird nicht mehr verwendet, wenn man Gleitpunktoperationen haben will, die performen.

#1: y = a x^2 + bx + c #2: y = a * sqr(x) + b * x + c; #3: x a over * b + * c +

Und du behauptest, #1 und #3 sind ähnlicher als #1 und #2? Hälst du dir die Augen zu und singst laut "lalalala", damit du die Realität nicht wahrnehmen musst? Das ist echt absurd.

Gacker!

Ja, alles Probleme, die sich in Hochsprachen überhaupt nicht in den Griff kriegen lassen, weil man natürlich KEINERLEI Einfluß auf die Operatorenreihenfolge hat. Klammern und so gibts da ja nicht, gell. Das geht nur mit UPN, eindeutig.

Jungejunge, du bist wirklich ABSURD ahnungslos und ignorant. Das ist echt schon nicht mehr witzig, sondern einfach nur verblüffend.

Weißt du was ne richtig schlechte Angewohnheit ist? Im Usenet Lügen zu erzählen. Zum Beispiel hattest du mir doch versprochen, mich in deinem Killfile "schmoren" zu lassen. Offenbar war das aber gelogen.

Lieber DoDi, kannst du mir bitte einen großen Gefallen tun und mich da wieder aufnehmen? Ich fände es echt cool wenn du deine bizarren Absurditäten für dich behalten würdest, weil du von mir weniger mit der Realität konfrontiert wirst.

Vielen Dank im Voraus, Alles Liebe, Johannes

dann würdest du Belege zu Behauptungen anführen, statt einfach nur Geschichten zu erfinden.

Und habe ich nie angezweifelt. Wohl aber deine dubiosen Geschichten, die sich alle als erfunden oder gelogen rausstellen. Wer hätte es gedacht? Ach ja stimmt, jeder hätte es gedacht.

Ich weiß nicht wie du auf den Trichter kommst, ich hätte das geleugnet. Das Gegenteil ist der Fall.

Du lässt einfach immer gezielt alle die Information weg, bei der du als dreister Lügner entlarvt wirst und versuchst, anderen Leuten irgendwas in den Mund zu legen. Absolut unredlich.

Wo sind denn die Datenblätter zu den Forth SPSen? Lego Mindstorms? Cryptokarten? Die hattest du bequemerweise vergessen. Ich hol schonmal Popcorn, während du die raussuchst.

Hä? "Riad" *ist* die korrekte Schreibweise. Oder wovon redest du? Du hattest in deinem Posting von "Rihad" geschrieben, schon vergessen? Lies es dir doch nochmal durch, Microprofessor.

Endlich mal ein Punkt, in dem wir vollständig einer Meinung sind. Vielleicht werden wir ja doch noch allerallerbeste Freunde!

Viele Grüße, Johannes

Ahahaha, ist mir gerade erst aufgefallen! Dann schauen wir doch mal:

a x dup * + b x * + c +

a x x * + b x * + c +

a x2 + b x * + c +

Ist also:

(a + x²) + bx + c

Gefordert war aber

a * x² + bx + c

Geil! Schöner hätte ich nicht beweisen können, dass UPN eben Grütze ist.

Danke dir, Johannes

Schön, wenn der Computer das kann, ich kanns auch und finde es einfacher (für mich)

Saludos (an alle Vernünftigen, Rest sh. sig) Wolfgang

Da hat der Deutsch-Oberlehrer aber etwas gepatzt :p Wolfgang iss ne Petze! Ätsch!

Na wenn Du meinst.

Und stimmt offensichtlich trotzdem nicht, es fehlt noch das speichern nach y, also der Term y=, hätteste besser 6x angesehen :p

und ich nicht einmal :p a x x * * b x * + c + im hp-16C style y ist TOS a x ^2 b x * + c + TO Y im Forth style vom TOS zu y :D :D

Achso die Variablen fehlen noch, also vorher (bei mir) deklarieren. Du tippst Dir die Finger wund, ich nur incl. gleich vorbesetzen mit a=1 x=2 b=3 c=4 y=0, guckstu wie schön:

Ach so, y und y soll public sein, a b c locals? Hammwa och:

kNAN VALUE x kNAN VALUE y

dann eben in der entsprechenden Routine .. LOCALS| a b c | 1 TO a 3 TO b 4 TO c ..

Feddich iss die Laube :)

BTW kNAN ist bei mir eine Konstante (desterwegen kname) die Not A Number repräsentiert, ist nicht Standard, aber sehr brauchbar beim debuggen.

den ganzen Schmonzes möchtest du OCTAL? dann tip es doch einfach OCTAL Hexadecimal gefällig? tippere HEX, Binary dann doch? ok, gibbet auch: BINARY eintippen und zurück zu decimal mit eben diesem DECIMAL

Präfixe für HEX ... gibbet latürnich auch

Und wenn Du neugierige vertreiben willst, dann eben

DECIMAL 36 BASE !

Dann kannst mit 0..9 A..Z rechnen :)

So kann man u.a. sein Copyright verstecken/schützen. Bei einem x64 FORTH mit 128bit doubles, könnte man schon ganz schön lange Texte verstecken.

Oder lieber im Trinär System?

So einfach ist FORTH

Man erkennt, dass wir unterschiedliche Sichtweisen haben. Meine UPN-Sicht ist einfach klar, gut lesbar und ohne Klammeritis...

Saludos (an alle Vernünftigen, Rest sh. sig) Wolfgang

Hier noch was für FORTH Kennenlernmöchter:

Saludos (an alle Vernünftigen, Rest sh. sig) Wolfgang