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

[Hans-Peter Diettrich]

Am 17.08.2019 um 13:53 schrieb Wolfgang Allinger:

On 17 Aug 19 at group /de/sci/electronics in article grppjtFhtebU2@mid.individual.net
DrDiettrich1@aol.com> (Hans-Peter Diettrich) wrote:

Am 17.08.2019 um 05:34 schrieb Wolfgang Allinger:

Daß uncompiliertes FORTH nicht besonders effizient ist,
darauf habe ich ja bereits hingewiesen. Schau mal in eine (embedded)
FORTH Gruppe, wenn Du etwas über professionelle Anwendungen erfahren
möchtest.

Hä? Forth compiliert doch schon während der Eingabe, es gibt keine
unkompilierten Programme, wenn das Forth läuft. Wenn Du den OK Prompt
siehst, ist das Programm kompiliert.

Ist nicht wie bei Basic!

Bei BASIC ist das nicht anders: Eingaben werden in Binärcode (p-code...)

Nein, BASIC interpretiert immer wieder, erst ein BASCOM setzt das als (p-
code) um, aber dann ist die Interaktivität futsch!

Mit solchen "Experten" möchte ich nicht weiter über Programmiersysteme
diskutieren :-(

DoDi

 

[Johannes Bauer]

On 17.08.19 12:17, Wolfgang Allinger wrote:

Es ist eine der längeren Zeiten, die ich gebraucht habe. Python waren
vielleicht 5 Minuten, ein "hello world" in C braucht 10. Go waren auch
etwa 5 Minuten, das weiß ich noch ganz genau, weil es nicht so lange her
ist.

Hello World dauert in FORTH nur solange, wie man tippen muss

OK> : Hello ." Hello World, hello Johannes" ; Hello <CR
mit dem <CR> ist es bereits kompiliert und ausgefĂźhrt,

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

Auch wenn du die RPN gut findest, mir stellen sich die Nackenhaare auf
und ich finde das grotesk unĂźbersichtlich.

Damit ist klar, dass Du zu denen gehĂśrst, die niemals FORTH kennen und
kĂśnnen wirst.

Spar Dir die MĂźhe.

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".

Ja sehr einsteigerfreundlich, wenn man erstmal den Compiler/Interpreter
auf das Target portieren muss.

Quatsch mit Sosse, auf neuen Kern anpassen (1-3d Manntage) muss man nur,
wenn man FORTH auf einen neuen Processor bringen will und man im Netz
keinen passenden Kernel findet. Mach das mal fĂźr C... MannMonate/Jahre?

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.

Wenn die Engine läuft, kannst Du alle bisher (nicht maschinenspezifische)
FORTH Programme laufen lassen, die mit Standard I/O auskommen. Mach das
mal in einer anderen Sprache oder versuch mal andere Interpreter auf eine
neue CPU zu bringen, oder Dein geliebtes C.

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.

Ich kenne nur 2 CPUs, fĂźr die
es kein FORTH gibt, die eine waren die Ur-PICs, und dann war da noch
irgendeine, die ich und die Welt längst vergessen hat. Irgendwas war da
mit der Art des Speicherzugriffs (Harvard Ecke?).

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

Ohne Linker ist offenbar 500 Mal besser als mit.

Keine Ahnung wie Du auf diesen blĂśden Trip kommst.

Der "blĂśde Trip" ist eine objektive Messung, die du jederzeit nachprĂźfen
oder entkräften kÜnntest.

> Als grobe Faustformeln:

Nein.

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

1. Eine FORTH Anwendung oberhalb des Kernels braucht nur 1/10 des Platzes
herkĂśmmlicher Programme. Kleinster Kernel, den ich mal kompiliert hatte,
passte in 2kB.

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.

2. FORTH Geschwindigkeit liegt auf der Scala ASM = 1 und Basic = 100, etwa
bei 10. Mit Gewalt auch weit niedriger, bis an <2, aber dann ist alles in
FORTH CODE-definitions umgefrickelt und vĂśllig ĂźberflĂźssig, und alle IR
sind auch CODE, was i.a. ebenfalls nicht benĂśtigt wird. Man kann IR
durchaus in HLL benutzen, wenn Du eine schnelle CPU oder nicht
hyperventilierende IRs hast.

Noch mehr dahergefibertes Gelaber. Ich habe gemessen: C = 1, Forth =
500. Alles dokumentiert, der Code offen, die Messmethode dazu. Und du
kriegst es nicht widerlegt. Komisch, oder?

[mehr fibriges Gelaber gesnippt]
> Alles NichtskĂśnner? Alle mĂśgen kein RPN?

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
500 steht im Raum) als der Äquivalente C Code ist. Mehr nicht. Dass ich
RPN nicht mag, ist meine Präferenz, ßber Geschmack will ich nicht streiten.

Gruß,
Johannes

 

[Johannes Bauer]

On 17.08.19 13:12, Wolfgang Allinger wrote:

Son gequirlter Quatsch. Im parallelen Posting beschreibe ich zwei Monster
US PrĂźfanlagen, kannst ja mal die Datenrate nachrechnen...

Ich hab da keine Zeit zum zerpflĂźcken Deiner kruden VorwĂźrfe.

LOL ich habe *gemessen*. Wenn du objektive Zahlen nichts
entgegenzusetzen hast, hast du das Argument in dem Bereich verloren.

Keine Ahnung, was Du da mit RC4 gemacht hast, hab weder Zeit noch Lust das
nachzugroffeln.

Aaaaaaaaahahahahaha! BWAHAHAHAHAHAHA!

Kann nichtmal ein Programm, das die Komplexität eines "Hello World" nur
marginal Ăźberschreitet, selbst ausfĂźhren und Messungen durchfĂźhren.
Respekt, Respekt, du bist ja ein echter Spezialexperte.

Ich hab hier Ăźbrigens auch kalte Fusion am Laufen und ein Perpetuum
Mobile, aber ich hab jetzt keine Zeit noch Lust die Pläne hochzuladen.
Glaub es mir einfach!!!1111elf

Du wechselst bei deiner Argumentation STÄNDIG das Ziel. Und DEINE
Behauptungen sind krude, dann zeig doch mal Messungen von angeblichem
GranatenzĂźndcode und Echtzeitberechnungen von Flugraketen. Ach, kannst
du nicht, weil das ist alles nur HĂśrensagen? Messungen hast du nicht?
Dann ist es nur Geschwurbel.

Du spinnst, haste mal was von NDA gehĂśrt oder kennst Dich im MIL Bereich
aus?

Aaaaaaaaah ja klar, der NDA hindert dich daran, ein Hello World
auszufĂźhren! Is klar, MĂźnchhausen.

Butter bei die Fische! Zeigen, nicht Labern. Zeig doch mal wie
performant das sein kann. Der Faktor 500 ist jetzt schonmal eine Zahl,
die objektiv belegt ist, auch wenn du mit der Realität nicht so klar kommst.

Kann durchaus sein, dass in irgendwelchen Spezialanwendungen Hardware
gebaut wurde, die das performant interpretiert. Aber auf einem
"normalen" Target läuft es halt echt Kacke langsam.

Schmeisst Du hier ständig Interpreter und Compiler durcheinander?
Wenn FORTH fertig mit dem Lesen einer Quelle ist, ist wenige
Maschinenzyklen später auch das Kompilat fertig!

Das kommt ja wohl aufs Target an. Du erzeugst Bytecode und der wird
interpretiert. Auf einer Maschine, die Bytecode nativ ausfĂźhren kann wie
dem RTX2000 wird der direkt ausgefĂźhrt, aber Ăźblicherweise redet man bei
Bytecode von Interpretation.

Noch ganz zum Schluss: beim RTX2000 hab ich einen IR Eingang mit 2MHz
getriggert und auf einem weiteren mich mich 9600Bd seriell mit dem
Kerlchen unterhalten, ohne das man da was von der Grundlast merkte. und
das in den 1980ern.

Also deine Behauptung und neuerliche Anekdote ist, dass du eine
Interruptfrequenz von 2 MHz in den 80ern so "nebenbei" hattest? Das ist
schlicht und ergreifend gelogen und wenn du nur halb der Ingenieur
wärst, der du behauptest zu sein, dann hättest du das auch sofort
durchschaut. Rechne mal bei einen minimalen ISR (nicht in Hardware
implementiert, sonst ist es ja kein Argument fĂźr Forth) die Anzahl der
Instruktionen, um was sinnvolles zu machen durch.

Ich hab ja nicht gesagt, dass die 2MHz was besonders sinnvolles gemacht
haben. Der RTX2000 fĂźhrt eine leere Interrupt Service Routine in 400ns
aus. Jeder zusätzliche (Anwendertakt) 100ns. zB. Einen Zähler zu
incrementieren 100ns. In diesen 100ns konnte der bis zu 4 (5?) Befehle
gleichzeitig ausfĂźhren. zB. noch an nem Portbit wackeln. Dazu war eben
noch genĂźgend Zeit, um per SIO mit dem Target zu arbeiten. Nix HW, alles
SW!

Na dann faktenchecken wir doch mal deine Behauptungen. Der RTX2000 ist
eine 10MHz MCU. Die Interruptlatenzzeit sind vier Zyklen. Das heißt, du
hast bei deiner 2 MHz IRQ Frequenz noch genau eine Instruktion Ăźbrig,
wenn du Ăźberhaupt im ISR angekommen bist. Und irgendwann willst du die
ISR auch wieder verlassen, da geht deine letzte Instruktion hin.

HĂśr doch endlich auf so dummdreist und durchschaubar rumzulĂźgen. Jede
technische LĂśsung hat Vor- und Nachteile. Gib doch einfach zu, dass
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.

Watt nu? Das habe ich gemessen und vorgefĂźhrt, kann leicht anhand des
Datenblattes RTX2000 ĂźberprĂźft werden. Wenn man will.

Ja, habe ich ja oben ĂźberprĂźft. Bist aufgeflogen.

Das ist eben der Unterschied zwischen Ingenieuren hĂźstel Bahnhofsnutten
und Physikern

Ach ne, wĂźrde ich gar nicht auf den Unterschied schieben, sondern es
gibt halt intellektuell grundlegend unehrliche Leute wie du, die einfach
Fakten wegignorieren, die ihnen nicht passen.

Und tut mir leid, dass der RTX2000 keinen Assembler als Maschinencode hat.
Nur FORTH Er besteht IIRC aus etwas mehr als 4.000 Gattern. Der
Vorläufer NOVIX 4000 hatte daher seinen Namen.

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
NICHT spezifisch fĂźr eine Sprache geschrieben, sondern die ISAs haben
sich durchaus weiterentwickelt. Dann hat man halt auch mehr Auswahl an
Hardware als nur n Paar obskure Spezialprozessoren.

Ich weis auch nicht, was moderne uC fĂźr eine leere IRsrv brauchen. Ist mir
auch egal, die RTX2000 waren ja schon mal ne Hausnummer.

Noch nen Massenartikel: die ZĂźndschlĂźssel fĂźr viele Autos, besonders
Mercedes, hatten einen MARC 4 (4!!! bit FORTH Processor) von Temic (ex
Telefunken) drin. Nein, MERCEDES hat das nicht besonders geschickt und
vorbildlich implementiert, sitzen auf zu hohem Ross
Einer der MIL Wegwerfartikel hatte auch nen MARC4 drin, im Gegensatz zu
den DĂźsseldorfern, die haben 100 Tausende RTX im Desert Storm verfeuert.
Desterwegen sind die Dinger inzwischen auch sehr rar geworden.

Waren Granaten, die im Endanflug Ăźber kleine Finnen mit Schrittmotoren
(armer Johannes), sowie mit Video und Radar im Kopf gesteuert wurden.
Anfangsbeschleunigung umme 30.000g
Und ich glaube nicht, dass das eine langsame Anwendung war Oder die
FORTH wegen Lahmheit genommen haben.

Ich empfehle dir Paracetamol gegen das Fiber, dann morgen frĂźh gleich
zum Arzt. Das kĂśnnte was ernstes sein.

Ja, C Compiler gibt es halt fĂźr jedes Target ohne dass man das erst
Compiler portieren mĂźsste.

Hab ich irgendwo geschrieben, dass ich fĂźr den C166 nicht einen fertigen
Kernel genommen habe? Ich hatte in meinem Ing. BĂźro die Kernels fĂźr 2
Dutzend verschiedenen CPU Familien im KĂścher. Ja alle zugekauft und einen
selber gemacht um das auch mal probiert zu haben. Wieviel C Kerne hast Du
schon geschrieben?

Was soll denn ein "C Kern" sein? Hast du auch nur die leisteste Ahnung
davon, wie ein moderner Compiler Ăźberhaupt funktioniert? Ich habe LLVM
mal retargetiert, ja, und der kann dann u.a. C kompilieren. Ist nicht
schwierig, wenn man weiß was man macht. Muss man aber i.d.R. nicht, weil
es eben fĂźr quasi JEDEN Prozessor schon einen C Compiler gibt, und man
die weder "zukaufen" muss noch selber machen.

Was hast Du an dem Begriff "erstellen eines Target fĂźr eine NEUE CPU"
nicht verstanden?

Was hast du denn daran nicht verstanden, dass es fĂźr jedes Target schon
einen C Compiler gibt, ohne dass man was erstellen muss?

Gruß,
Johannes

 

[Wolfgang Allinger]

On 17 Aug 19 at group /de/sci/electronics in article qj9hf6$9a8$1@news2.open-news-network.org
<dfnsonfsduifb@gmx.de> (Johannes Bauer) wrote:

Gruß,
Johannes

Hab ein schönes Leben und leck mich...


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

--
Ich bin in Paraguay lebender Trollallergiker reply Adresse gesetzt!
Ich diskutiere zukünftig weniger mit Idioten, denn sie ziehen mich auf
ihr Niveau herunter und schlagen mich dort mit ihrer Erfahrung!
(lt. alter usenet Weisheit) iPod, iPhone, iPad, iTunes, iRak, iDiot

 

[Wolfgang Allinger]

On 17 Aug 19 at group /de/sci/electronics in article qj9imo$a98$1@news2.open-news-network.org
<dfnsonfsduifb@gmx.de> (Johannes Bauer) wrote:

On 17.08.19 13:12, Wolfgang Allinger wrote:

Son gequirlter Quatsch. Im parallelen Posting beschreibe ich zwei Monster
US Prüfanlagen, kannst ja mal die Datenrate nachrechnen...

Ich hab da keine Zeit zum zerpflücken Deiner kruden Vorwürfe.

LOL ich habe *gemessen*. Wenn du objektive Zahlen nichts
entgegenzusetzen hast, hast du das Argument in dem Bereich verloren.

Keine Ahnung, was Du da mit RC4 gemacht hast, hab weder Zeit noch Lust das
nachzugroffeln.

Aaaaaaaaahahahahaha! BWAHAHAHAHAHAHA!

Kann nichtmal ein Programm, das die Komplexität eines "Hello World" nur
marginal überschreitet, selbst ausführen und Messungen durchführen.
Respekt, Respekt, du bist ja ein echter Spezialexperte.

Dummbatz.

Ich hab hier übrigens auch kalte Fusion am Laufen und ein Perpetuum
Mobile, aber ich hab jetzt keine Zeit noch Lust die Pläne hochzuladen.
Glaub es mir einfach!!!1111elf

Du wechselst bei deiner Argumentation STÄNDIG das Ziel. Und DEINE
Behauptungen sind krude, dann zeig doch mal Messungen von angeblichem
Granatenzündcode und Echtzeitberechnungen von Flugraketen. Ach, kannst
du nicht, weil das ist alles nur Hörensagen? Messungen hast du nicht?
Dann ist es nur Geschwurbel.

Du spinnst, haste mal was von NDA gehört oder kennst Dich im MIL Bereich
aus?

Aaaaaaaaah ja klar, der NDA hindert dich daran, ein Hello World
auszuführen! Is klar, Münchhausen.

Du idiotisches vielbeiniges Rumpelstilzchen hüpfst ständig auf
verschiedenen Beinen rum. Erst faselst Du was, ich solle was über die
Proggies in den Granaten veröffentlichen, als ich dann sage, darf ich
nicht... wg. NDA sabbelst Du was von Hello World und Geschwurbel?

Was bist Du für ein Arschloch!

Butter bei die Fische! Zeigen, nicht Labern. Zeig doch mal wie
performant das sein kann. Der Faktor 500 ist jetzt schonmal eine Zahl,
die objektiv belegt ist, auch wenn du mit der Realität nicht so klar
kommst.

Kann durchaus sein, dass in irgendwelchen Spezialanwendungen Hardware
gebaut wurde, die das performant interpretiert. Aber auf einem
"normalen" Target läuft es halt echt Kacke langsam.

Schmeisst Du hier ständig Interpreter und Compiler durcheinander?
Wenn FORTH fertig mit dem Lesen einer Quelle ist, ist wenige
Maschinenzyklen später auch das Kompilat fertig!

Das kommt ja wohl aufs Target an.

Nein, ist Eigenheit von Forth

Du erzeugst Bytecode und der wird
interpretiert. Auf einer Maschine, die Bytecode nativ ausführen kann wie
dem RTX2000 wird der direkt ausgeführt, aber üblicherweise redet man bei
Bytecode von Interpretation.

Und Forth hat zwei Interpreter, den inner und den outer interpreter. Der
outer ist praktisch die User Schnittstelle und der inner halt für den
Ablauf des compilierten Code zuständig. wg. mir kannste das Bytecode
nennen, obwohl das bei FORTH noch wal wieder was ganz anderes ist.

Noch ganz zum Schluss: beim RTX2000 hab ich einen IR Eingang mit 2MHz
getriggert und auf einem weiteren mich mich 9600Bd seriell mit dem
Kerlchen unterhalten, ohne das man da was von der Grundlast merkte. und
das in den 1980ern.

Also deine Behauptung und neuerliche Anekdote ist, dass du eine
Interruptfrequenz von 2 MHz in den 80ern so "nebenbei" hattest? Das ist
schlicht und ergreifend gelogen und wenn du nur halb der Ingenieur
wärst, der du behauptest zu sein, dann hättest du das auch sofort
durchschaut. Rechne mal bei einen minimalen ISR (nicht in Hardware
implementiert, sonst ist es ja kein Argument für Forth) die Anzahl der
Instruktionen, um was sinnvolles zu machen durch.

Ich hab ja nicht gesagt, dass die 2MHz was besonders sinnvolles gemacht
haben. Der RTX2000 führt eine leere Interrupt Service Routine in 400ns
aus. Jeder zusätzliche (Anwendertakt) 100ns. zB. Einen Zähler zu
incrementieren 100ns. In diesen 100ns konnte der bis zu 4 (5?) Befehle
gleichzeitig ausführen. zB. noch an nem Portbit wackeln. Dazu war eben
noch genügend Zeit, um per SIO mit dem Target zu arbeiten. Nix HW, alles
SW!

Na dann faktenchecken wir doch mal deine Behauptungen. Der RTX2000 ist
eine 10MHz MCU. Die Interruptlatenzzeit sind vier Zyklen. Das heißt, du
hast bei deiner 2 MHz IRQ Frequenz noch genau eine Instruktion übrig,
wenn du überhaupt im ISR angekommen bist. Und irgendwann willst du die
ISR auch wieder verlassen, da geht deine letzte Instruktion hin.

Die komplette leere IRsrv dauert mit Aufruf *und* Rückkehr 400ns,
dann noch 100ns für bis zu 4(5?) gleichzeitige Befehle reicht um einen
Zähler zu incrementieren, zusammen also 500ns. Und dann kannste mit 2MHz -
10Hz (für Dich Erbsenzähler) noch locker mit dem Kernel per COM quasseln.

Wenn ich das noch richtig im Kopf habe, macht der RTX den 'RETI' ohne
zusätzliche Zeit, hängt mit der Art, wie Forth funzt zusammen. Aber ist
25a her, dass ich das zuletzt gemacht habe.


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

Hör doch endlich auf so dummdreist und durchschaubar rumzulügen. Jede
technische Lösung hat Vor- und Nachteile. Gib doch einfach zu, dass
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.
[...]
Ja, habe ich ja oben überprüft. Bist aufgeflogen.
[...]
Ach ne, würde ich gar nicht auf den Unterschied schieben, sondern es
gibt halt intellektuell grundlegend unehrliche Leute wie du, die einfach
Fakten wegignorieren, die ihnen nicht passen.
[...]
Hardware als nur n Paar obskure Spezialprozessoren.
[...]
Ich empfehle dir Paracetamol gegen das Fiber, dann morgen früh gleich
zum Arzt. Das könnte was ernstes sein.

Was hast Du an dem Begriff "erstellen eines Target für eine NEUE CPU"
nicht verstanden?

Was hast du denn daran nicht verstanden, dass es für jedes Target schon
einen C Compiler gibt, ohne dass man was erstellen muss?

Ach und wer erstellt die 1. Version für ein Target? Egal ob C oder Forth?
Bei C wächst das bei Dir wohl von den Bäumen, bei Forth erledigt das eine
einzelne Seele in 1-3 Tagen.

Gruß,
Johannes

Nochmal ...leck mich und hasta la vista



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

--
Ich bin in Paraguay lebender Trollallergiker reply Adresse gesetzt!
Ich diskutiere zukünftig weniger mit Idioten, denn sie ziehen mich auf
ihr Niveau herunter und schlagen mich dort mit ihrer Erfahrung!
(lt. alter usenet Weisheit) iPod, iPhone, iPad, iTunes, iRak, iDiot

 

[Johannes Bauer]

On 18.08.19 01:02, Wolfgang Allinger wrote:

Ich hab da keine Zeit zum zerpflĂźcken Deiner kruden VorwĂźrfe.

LOL ich habe *gemessen*. Wenn du objektive Zahlen nichts
entgegenzusetzen hast, hast du das Argument in dem Bereich verloren.

Keine Ahnung, was Du da mit RC4 gemacht hast, hab weder Zeit noch Lust das
nachzugroffeln.

Aaaaaaaaahahahahaha! BWAHAHAHAHAHAHA!

Kann nichtmal ein Programm, das die Komplexität eines "Hello World" nur
marginal Ăźberschreitet, selbst ausfĂźhren und Messungen durchfĂźhren.
Respekt, Respekt, du bist ja ein echter Spezialexperte.

Dummbatz.

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

 

[Ewald Pfau]

Johannes Bauer <dfnsonfsduifb@gmx.de>:

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.

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.

 

[Johannes Bauer]

On 18.08.19 09:30, Ewald Pfau wrote:

Johannes Bauer <dfnsonfsduifb@gmx.de>:

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.

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.

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
10 langsamer als C), aber der Faktor 500 hat mich schon sehr erschreckt.
Insbesondere weil gforth von Wolfgang selbst als reife Implementierung
bezeichnet wurde hätte ich gedacht, dass das zumindest fßr so simple
Fälle gut optimiert ist.

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.

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.

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?

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.

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.

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.

Auf dem kann ich aber nicht testen

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.

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

 

[Ewald Pfau]

Johannes Bauer <dfnsonfsduifb@gmx.de>:

On 18.08.19 09:30, Ewald Pfau wrote:

Hmm, naja wie gesagt, wenn es etwas besseres gibt auf FORTH-Seite, dann
wĂźrde ich das auch gerne ausprobieren. Kennst du eine Alternative?

Nun ja, Forth ist eher schon eine Lebensanschauung und der bin ich in weiten
StĂźcken nicht mehr gar so in Treue verknĂźpft. PHP, die Bash oder awk haben
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
ist, und es je nach Aufgabe biegt und windet, bis es passt. Hatte Ăźber Jahre
z.B. Primzahlen rechnen lassen, das ging dann mehr und mehr in Assembler.
Man weiß dann, was man tut, und lässt nur den Oberflächenkomfort in
Secondaries stehen (also in Forth-Worten, die aus Tokens bestehen).

FĂźr die typischen Erwartungen dieser nunmehr anderen Zeiten wird eher der
Output eines Compilers konsumiert als wie eine Service-Leistung.

Dazu verweise ich denn auf eines der Softwarehäuser fßr Forth, auf deren
Ebene ist das auch eher die Vorstellung von ihrem Zielpublikum, siehe die
Rubrik fĂźr uCs:

https://www.forth.com/embedded/

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

Dort auf der Seite sind zwei Beispiele fĂźr den generierten Assembller-Output
von kurzen Routinen, plus die Wirkung des Optimizers.

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
10 langsamer als C), aber der Faktor 500 hat mich schon sehr erschreckt.

Derart langsam finde ich das auch inakzeptabel. Hatte einst eine Idee von
Langsamkeit, als bei mir ein Forth-Interpreter, mit sehr wenig Assembler
innen drin, fĂźr einen 8051er, zum ersten Mal lief. Er machte dasselbe wie
das Forth fßr den Desktop daneben, etwa äquivalente Sourcen (aber weit
weniger in Assembler, viel mehr in Secondaries) fĂźr die Grundlagen. Faktor
500 langsamer - vielleicht, hab's nicht gemessen. Hab mich nur dabei nett
amĂźsiert. Aber auf dem Desktop ist das schon etwas arg daneben.

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?

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
nachgebildet wurde. Und das verlangt eben die KlimmzĂźge dafĂźr, wie kommt die
Laufzeitumgebung an die Parameter, die auf dem Forth-Stack liegen sollten,
der aber erst einmal zu emulieren ist, wenn der eine Stack zugleich der
Returnstack ist. Ob das jetzt das Modell von dieser Implementation war, weiß
ich nicht mehr, nur, dass hier KlimmzĂźge anfallen.

Diese Klimmzßge sind dann aber komplett low-level ständig im Einsatz, das
sind dann lauter leere Kilometer an Prozessorzeit. Eine fette Party fĂźr
Flaschenhälse.

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.

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?

Wollte jetzt nicht die gefinkelten C-Compiler dagegenhalten.

Die Optimiererei fängt in Forth beim programmierenden Personal an, das die
Übersetzung von Algorithmen in stack-basierte Formulierungen auf die Beine
bringt, auf dass mĂśglichst wenig Akrobatik beim Verkehr des Herumschiebens
der anonymen Parameter auf dem Stack anfällt.

Wenn man das nicht will, schreibt man mit Variablen (oder Local Values) und
ist dann der algebraischen Notierung (wie in C usw.) gleich wieder näher.
Das macht man spätestens, wenn der Code ßberfrachtet wird mit den DUP SWAP
ROT TUCK OVER usw.

Aber das ist auch ein Grund fĂźr die Tendenz, kurze Routinen unbedingt zu
bevorzugen, da ist der Verkehr auf dem Stack Ăźberschaubarer. Also die
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
dessen Aufruf gibt. Beim expliziten Speichern fällt das weg (außer bei
Local Values, aber die gehen dann in die Richtung, dass ein Frame bei Aufruf
zwischengesichert werden und beim Verlassen wieder restauriert werden muss -
aber vielleicht bĂźgeln fixe Forth-Optimierer da auch schon einiges weg, in
der Zwischenzeit, nicht mehr geschaut habe solches dann mehr).

Wenn man sich mit dem klassischen Modell begnügen kann, dass auch für große
Abläufe der Stack als Datenspeicher ausreicht, dann gibt es bei der
Abarbeitung der Tokens eben keine andere Instanz, die quasi hinter dem
RĂźcken bedient werden muss, bevor die Routine direkt dem Zweck entsprechend
abläuft. Sie ist dann direkt und ohne Umschweife zur Verfßgung,
laufzeittechnisch.

Der einzige Overhead ist dann das NEXT, das von einem Token zum nächsten
weiterschaltet. Und das ist schnell: den reservierten IP inkrementieren,
lesen, die gelesene Adresse anspringen. HierfĂźr ist ein CPU-Register als IP
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
berĂźhrt den Datenstack nicht. Es muss also nur der Laufzeitapparat umgeladen
werden, die Daten selbst bleiben transparent in VerfĂźgung.

Man kann das dann anders auch sehen: Die klassische Implementation fĂźhrt ein
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.

Assembler plus Optimierung mĂśchten aber lieber die ganze CPU fĂźr sich. Das
ist ein Punkt und der nächste dann gleich - Forth wird auf eine CPU hin
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.

FĂźr uCs hingegen ist das ein gangbares Szenario, eben wie auch fĂźr die
lowlevel-Umgebung des Open-Boot im BIOS von Desktops.

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.

Die Optimierer sind schon hypsch mächtig geworden, ja. Wenn aber fßr obiges
Modell jedes kurze Forthwort ein eigenes C-Kompilat darstellen soll, hat der
Optimierer fĂźr den Ablauf des Codes, von mehr Distanz betrachtet, eher
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.,
typische Abfolgen (die nach hunderten zählen), die sich leicht in Assembler
darstellen lassen, wurden aufgefunden und zusammengefasst.

Und Ăźber all dem aber, um das nicht zu vergessen, sitzt die Idee des
strikten One-Pass-Compilers. Es ist ja nicht traditionellerweise das
Kompilat das Ziel, weswegen ein Quelltet geladen wird, sondern, abstrakter,
irgendeine Erledigung von irgendeiner Aufgabe. Da kĂśnnte die Bindung an die
Eigenart auch stĂśrend werden, wenn alles, was geschieht, in mehreren
Passagen wiederauftaucht.

Man kann sich aber, seit dem ANS/ISO-Modell, mit den Mitteln zur
Interpretersteuerung unterwegs gern seinen Mehr-Pass-Compiler stricken. Das
gehÜrt zum Chamäleon dazu, ebenso, wie man unterwegs kurz umschalten kann,
einen BASIC-Interpreter stricken (bzw. fĂźr FORTRAN kam das gelegentlich in
Umlauf) und hernach ein StĂźck algebraische Notation abarbeiten. Diese
monokausal gestrickte Denkweise, wozu der Quelltext und wozu der Compiler
diene, ist eine gutes StĂźck zu eng, fĂźr das, was man so alles auffĂźhren
kann.

Hatte das einst in Übung, eben, um per zweimal Laden eines Quelltextes einen
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
später, ein Stßck anders ineinandergreifen sollen, ist mehr eine
Engspursichtweise geworden, so ein Allzweckgerät geht dann in Richtung Exot
... und soll doch vor allem in Sachen Laufzeiten im erträglichen Rahmen
mithalten kÜnnen. Wenn es da herausfällt, ist auch mir das dann zu wenig.

Bei vielfach andersartiger Sichtweise muss das Ding ja nicht auf jedes
Siegertreppchen, aber mitspielen sollte es schon kĂśnnen. Interessant ist
mithin auch, dass man einige zu lÜsende Fälle um vieles anders anpackt, oder
Ăźberhaupt erst integrativ erledigen kann, verglichen mit den
Mainstream-Werkzeugen - wo manche Art von LĂśsung rein von der Art her, wie
man mit dem Werkzeug umgeht, nicht auf dem Radar aufscheinen wird. Sprich,
man hat deutlich mehr Freiheiten, und bezahlt dafĂźr mit entsprechend mehr
Disziplin, die zur Bändigung abverlangt wird - und sei es zur Bändigung nur
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.

 

[Gerhard Hoffmann]

Am 18.08.19 um 20:43 schrieb Ewald Pfau:

Johannes Bauer <dfnsonfsduifb@gmx.de>:

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
nachgebildet wurde. Und das verlangt eben die KlimmzĂźge dafĂźr, wie kommt die
Laufzeitumgebung an die Parameter, die auf dem Forth-Stack liegen sollten,
der aber erst einmal zu emulieren ist, wenn der eine Stack zugleich der
Returnstack ist. Ob das jetzt das Modell von dieser Implementation war, weiß
ich nicht mehr, nur, dass hier KlimmzĂźge anfallen.

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

Diese Klimmzßge sind dann aber komplett low-level ständig im Einsatz, das
sind dann lauter leere Kilometer an Prozessorzeit. Eine fette Party fĂźr
Flaschenhälse.


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.

Aber das ist auch ein Grund fĂźr die Tendenz, kurze Routinen unbedingt zu
bevorzugen, da ist der Verkehr auf dem Stack Ăźberschaubarer. Also die
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
dessen Aufruf gibt. Beim expliziten Speichern fällt das weg (außer bei
Local Values, aber die gehen dann in die Richtung, dass ein Frame bei Aufruf
zwischengesichert werden und beim Verlassen wieder restauriert werden muss -
aber vielleicht bĂźgeln fixe Forth-Optimierer da auch schon einiges weg, in
der Zwischenzeit, nicht mehr geschaut habe solches dann mehr).

Wenn man sich mit dem klassischen Modell begnügen kann, dass auch für große
Abläufe der Stack als Datenspeicher ausreicht, dann gibt es bei der
Abarbeitung der Tokens eben keine andere Instanz, die quasi hinter dem
RĂźcken bedient werden muss, bevor die Routine direkt dem Zweck entsprechend
abläuft. Sie ist dann direkt und ohne Umschweife zur Verfßgung,
laufzeittechnisch.

Der einzige Overhead ist dann das NEXT, das von einem Token zum nächsten
weiterschaltet. Und das ist schnell: den reservierten IP inkrementieren,
lesen, die gelesene Adresse anspringen. HierfĂźr ist ein CPU-Register als IP

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.

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
berĂźhrt den Datenstack nicht. Es muss also nur der Laufzeitapparat umgeladen
werden, die Daten selbst bleiben transparent in VerfĂźgung.

Man kann das dann anders auch sehen: Die klassische Implementation fĂźhrt ein
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.

Assembler plus Optimierung mĂśchten aber lieber die ganze CPU fĂźr sich. Das
ist ein Punkt und der nächste dann gleich - Forth wird auf eine CPU hin
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.

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

 

[Gerrit Heitsch]

On 8/18/19 9:57 PM, Gerhard Hoffmann wrote:

In aktuellen Intel-CPUs ist von 8086-Historie nichts mehr Ăźbrig. Das
sind jetzt multiskalare RISCs mit Hunderten von Registern und
spekulativer AusfĂźhrung.

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

 

[Gerhard Hoffmann]

Am 18.08.19 um 22:13 schrieb Gerrit Heitsch:

On 8/18/19 9:57 PM, Gerhard Hoffmann wrote:


In aktuellen Intel-CPUs ist von 8086-Historie nichts mehr Ăźbrig. Das
sind jetzt multiskalare RISCs mit Hunderten von Registern und
spekulativer AusfĂźhrung.

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

 

[Hans-Peter Diettrich]

Am 18.08.2019 um 21:57 schrieb Gerhard Hoffmann:

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

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

 

[Andreas Karrer]

* Gerhard Hoffmann <dk4xp@arcor.de>:

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

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

 

[Ralph Aichinger]

Andreas Karrer <ak-9a@gmx.ch> wrote:
> DEC hat sicher viele Fehler gemacht, aber Alpha gehĂśrte nicht dazu.

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
--
-----------------------------------------------------------------------------
https://aisg.at
ausserirdische sind gesund

 

[Eric Bruecklmeier]

Am 19.08.2019 um 07:21 schrieb Ralph Aichinger:

Andreas Karrer <ak-9a@gmx.ch> wrote:
DEC hat sicher viele Fehler gemacht, aber Alpha gehĂśrte nicht dazu.

Technisch sicher nicht, in der Vermarktung schon:

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

 

[Wolfgang Allinger]

On 19 Aug 19 at group /de/sci/electronics in article grv6svFmob5U1@mid.individual.net
<usenet@nerdcraft.de> (Eric Bruecklmeier) wrote:

Am 19.08.2019 um 07:21 schrieb Ralph Aichinger:
Andreas Karrer <ak-9a@gmx.ch> wrote:
DEC hat sicher viele Fehler gemacht, aber Alpha gehörte nicht dazu.

Technisch sicher nicht, in der Vermarktung schon:

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

Und bei DEC war der Kunde König, solange DEC der Kaiser war

Und weiter:
Es gibt 2 Arten der Geheimhaltung:
1. Nichts zu veröffentlichen
2. Alles zu veröffentlichen (DEC)

Es verging zu meinen DEC user Tagen, nicht ein Tag, wo ich in den
meterlangen AKtenordnern zu PDP11, RSX11M, RT02, RT11, LSI11... DECUS
nicht irgendwas gesucht und nicht gefunden habe Dafür aber vieles
entdeckte, was ich vergangene Woche dringend hätte gebrauchen können.

Bin manchesmal von Hürth zum TÜV in Köln (einige Dutzend km) gefahren,
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
Papertape-Rollen) ausgeliehen oder vorgeführt.
In vielen Prüfanlagen von uns steckte DEC.

Und um wieder OT zu werden
Mit der berühmten BYTE vom Aug1980(?) kam ich zum 1. Mal in Kontakt zu
FORTH. Hatte Mordsprobleme mit einer LSI02(?), RT11, Fremdcontroller für
Wechselwinchester und latürnich die Winchester von einem anderen
Zulieferer (IOMEGA?). DEC hatte nix kleines, was für Mannlochgängige KKW
Anlage ging. Jeder zeigte auf den anderen und ich sass in der Patsche bei
dem beliebten Kinderspielchen 'Schweinchen ärgern' oder 'Fang den Hut'.

Hab dann vom TÜV nen Lochstreifen mit FigForth ergeiert und dann damit
interaktiv die Sache erfolgreich debugged und hatte am Ende eine gute
Sammlung von Test 'Worten' in FORTH, die dann von unseren Serviceleuten,
als auch von DEC genutzt wurden. IIRC war das eine mistverständliche DEC
Doku, die sich auf dem Controller durch eine aufgekratzte Leiterbahn, eine
1n914 und etwas Wrapdraht flicken lies. Hab danach FORTH vergessen bis zu
einem grossen Projekt mit zuwenig Manpower, zuviel Rotstiften, Chaotischem
oberen Damagement und unglaublich knappen Zeitrahmen...: Herr Allinger,
sie sind nicht hier als Abteilungsleiter angestellt, um über Probleme zu
berichten, sondern um Lösungen vorzustellen!

Das Projekt bekam ich (mit meiner Abt. Für System und SW Entwicklung) aufs
Auge gedrückt, nachdem die HW Entwickler mit C in die Scheisse geritten
waren und absolut nix lief. Die HW Lieblinge der GL fielen nicht in
Ungnade, sondern die blöden Softies waren mal wieder zu dumm und zu faul!!

Ich hatte gerade Berichte von Mitch Bradley (SUN) gelesen, wo er
berichtete, wie er mit FORTH einen HDD Controller für eine nicht fertige
neue CPU (die er einfach mit FORTH emuliert hat) fertiggestellt hatte. Er
wurde in den Meetings immer als Spinner belächelt, konnte doch garnicht
sein, dass der Controller im Plan lag, wo doch die CPU noch garnicht
lauffähig war... Klarer Fall von zuviel Lötdämpfe und vernebeltem Gehirn,
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
erklären, wie er das Unmögliche geschafft hat. Er erfand dabei auch gleich
das Open-Boot (s.h. ebenda) und von da an gabs Open-Boot auf allen SUN.

MB: es ist schlimm, wenn sich keine Sau für Deine Arbeit interessiert und
nur über Dich lächelt. Aber noch schlimmer ist es, wenn sich jeder dafür
interessiert und Dein Labor dauernd voller Fremder ist

Später hat Mitch auch Java Entwicklung geleitet, warum der da allerdings
auf die 2 Stack Architektur von FORTH verzichtete, ist (mir)
unverständlich.

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
Seminar über Superprogramming.

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.

Ich für die HW, Forth-Kern und IR-Service, der 2. Ing nur für die
Anwendungsprogramme und der 3. Ing für die Bediener-Oberfläche. Mitten im
Projekt hab ich dann noch von dem zu klein werdenden Z80 auf 64180
umgestellt, die beiden anderen haben nichts bemerkt, ausser dass alles
viel schneller lief und deutlich mehr Speicher zur Verfügung stand.

Mission accomplished, haben Faktor >10 an Produktivität geschafft und
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!

Mit der Erfahrung an Produktivität... beschloss ich dann, die Fa. zu
verlassen um mein eigenes Ing-Büro. zu machen. Als das die anderen Beiden
mitbekamen (und noch ein weiterer), wollten sie mit mir gehen.

Ok, wir haben dann eine 4Mann SW-GmbH gegründet und zähneknirschend
ordentlich Projekte von dem alten AG mitbekommen. War ne prima Starthilfe.

Der einzige Fehler war, dass wir alle 4 gleichberechtige Partner waren.
Hab dann nach 5a und einem Firmen 924S eingesehen, dass nur Häuptlinge
und keine Indianer nicht klappte und dann mein eigenes Ing.Büro gemacht.

Hat mich meine Einlage von 20.000DM gekostet und den 924S hat dann einer
meiner exPartner weitergefahren (übrinx insgesamt fast problemlose 400Tkm
und dann an einen Zahnarzt weiterverkauft)

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
Katzen gut 'am Kacken gehalten' (O-Ton, Jürgen von Manger) sowie meine
geliebten Transaxle Porsche (weitere 4 von 7 Stück) samt ETW etc.
finanziert.

Der Rest ist Geschichte und ich nach rund 200 Aufträgen ausgewandert und
inzwischen in Rente gegangen.








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

--
Ich bin in Paraguay lebender Trollallergiker reply Adresse gesetzt!
Ich diskutiere zukünftig weniger mit Idioten, denn sie ziehen mich auf
ihr Niveau herunter und schlagen mich dort mit ihrer Erfahrung!
(lt. alter usenet Weisheit) iPod, iPhone, iPad, iTunes, iRak, iDiot

 

[Eric Bruecklmeier]

Am 19.08.2019 um 14:11 schrieb Wolfgang Allinger:

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
Katzen gut 'am Kacken gehalten' (O-Ton, JĂźrgen von Manger) sowie meine
geliebten Transaxle Porsche (weitere 4 von 7 StĂźck) samt ETW etc.
finanziert.

Der Rest ist Geschichte und ich nach rund 200 Aufträgen ausgewandert und
inzwischen in Rente gegangen.

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.

--
Ich muss nicht kultiviert *aussehen* - ich bin es.

Profiklaus in d.r.f.

 

[Axel Berger]

Eric Bruecklmeier wrote:
> 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.

--
/Ż\ No | Dipl.-Ing. F. Axel Berger Tel: +49/ 221/ 7771 8067
\ / HTML | Roald-Amundsen-Straße 2a Fax: +49/ 221/ 7771 8069
 X in | D-50829 Köln-Ossendorf http://berger-odenthal.de
/ \ Mail | -- No unannounced, large, binary attachments, please! --

 

[Eric Bruecklmeier]

Am 19.08.2019 um 15:51 schrieb Axel Berger:

Eric Bruecklmeier wrote:
und RPN finde ich schlichtweg abartig.

Das war ein Kompromiß, der von den Grenzen der Technik erzwungen wurde,

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

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.

ich wĂźrde mir das heute freiwillig nicht antun wollen.

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.

Stellt sich nur die Frage, was?


--
Ich muss nicht kultiviert *aussehen* - ich bin es.

Profiklaus in d.r.f.