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

[Wolfgang Allinger]

## forwarded copy of: EruqxzAUQoB@allinger-307049.user.uni-berlin
## date : 15.08.19
## newsgroup/archive: de.sci.electronics
## user : all2001@spambog.com (Wolfgang Allinger)


Örks, das sollte unter anderem subject raus, neuer Versuch, damit mans
wiederfindet


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

Am 15.08.2019 um 13:53 schrieb Wolfgang Allinger:

FORTH ist METAsprache, Scriptsprache, HLL und ASM, und zwar alles in
einem, so schnell mein Hirn und Finger wollen.

Hmm, welches FORTH hast Du da (für Skripte...) verwendet?

Kannst jedes dafür nehmen, was auf entsprechende Umgebung zugreifen kann.

Ich hab z.B. ausführbare Schriftstücke an meine Kunden verschickt, also
z.B. startup_4712.src, das System hab ich so eingerichtet, dass es beim
Start in einem bestimmten Verzeichnis (START nach ner neuen Datei
gesucht hat, wenn es die gefunden hat wurde die einfach interpretiert/
compiliert und die Anlage war wieder auf dem neuesten Stand.

So konnte man Patches oder Versuche einspielen, so dass der Kunde die
Abläufe/Parameter anpassen konnte. Wenn er zB. ne Kalibrierung geändert
hatte konnte er damit arbeiten, wenn er wollte, dann einfach
"startup_4712.src FSAVE" (kurz für FileSave) tippern und ENTER. Beim
nächsten Start war es dann, als wenns immer schon so geplant war.

Wenns nix war, dann per Editor, zB. dem im benutzten FORTH eingebauten
oder einen externen nehmen und startup_xxxx.src verbasteln.

Und warten, bis der eingewiesene Programmierer oder der Allinger ne
angepasste exe lieferte.

FORTH ist halt ein Interpiler und Compreter gleichzeitig.

Die Kunden (häufig Maschbauer) waren begeister, wie einfach sie was
verfummeln oder probieren konnten.

kurzes langatmiges Gesabbel von mir:
Beispiel Anfrage: wir ham jetzt 999 Geräte die nach einer besonderen
Justierung justiert werden sollen, wie geht das? Ich hab denen dann eine
datei geschickt, wo die HLL Definitionen drinstanden. Konnte er dann beim
nächsten Start mit der Eingabe Typ999 starten, wenn er wieder ein paar
normale Geräte dazwischen fahren wollte, dann eben nur START eingeben bzw.
das als letztes Wort in die update_Typ999 reinfrickeln, oder wenns
dauerhaft bleiben sollte, dann eben \ (Backslash) START einflicken und
darunter die Zeile Typ999 reinschreiben. Falls doch wieder wankelmütig,
dann eben das Kommentarwort "\ " vor Start weg und gut wars.
Alles was FORTH im Eingabestrom (prompt OK ) liest, wird bei einem <SP>
oder EOL als Wort behandelt und im Wörterverzeichnis nachgeschlagen und
ausgeführt, wenns nicht gefunden wurde, wurde versucht es als Zahl zu
verwursten, wenn ja, dann wurde die Zahl auf den STACK gelegt und weiter
geparst, wenn nicht, weil BlaFasel nicht gefunden wurde, kommt ein
"Blafasel is undefined" , der STACK wird gelöscht und der Eingabe prompt
'OK ' erscheint wieder für einen neuen Try und Error

(Mausmelodie tüdel füdel und das war der Forth Outer Interpreter

Der Outer Interpreter ist einfach die Endlosschleife, die auf Keys wartet.
Mit dem einfachen Wort ":" name bla blu blubber ; wird der Compiler
eingeschaltet und versucht eine neue Definition 'name' zusammenzubringen,
falls der Eingabestrom nur definierte Sachen finden, passiert
of(f)ensichtlich nix, bis das Wort ';' den Compiler wieder ausschaltet und
die Endlosschleife (Outer Interpreter) wieder einschaltet und auf neue
Worte wartet. Sonst kommt halt "blubber" is undefined. Das ist die Colon-
Definition, also der HLL Compiler.

undefined? Ja stimmt, HIV han ich verjässe, also fix

: blubber tüdelfüdel Tschingerrassabum Mausmelodie ; <CR>

eintippern und das Problem ist hoffentlich behoben.

Dann blubber eintippen und beobachten Was passiert? War nix? Doch lieber

: blubber füdel fiep tröt ; <CR>

blubber is redifined OK

Äh, hüstel, wollemer nit
FORGET blubber<CR>

OK

und alles ist wieder sauber.

Ahh ja, und wie ist das kompiliert? Der Compiler setzt ins RAM an die
Stelle für den Eintrag name eine Liste mit den Anfängen von füdel fiep
tröt rein. Das Wörterbuch zeigt einfach auf den Beginn von name und
feddich is die Laube.

Und wie läuft dann so ein Proggie ab? Wenn das Wort im Eingabestrom
gefunden wurde, hampelt der Inner Interpreter eifach die aktuelle Liste
ab. Also eine Liste mit Verweisen auf Listen von Listen... Es wird also
solange die Aufgabe vor sich hergeschoben, bis irgendwann in diesem
gefädelten Code irgendjemand aufgerufen wird, der weis was damit
anzufangen ist und dann zurückkehrt hinter den letzten Aufruf.

Kannste Dir also etwa so vorstellen, wie eine Liste mit CALL 1234 CALL
4567 CALL 8134 ... vobei der CALL niht drinsteht, sondern nur die
Verweisadresse und der Inner Interpreter macht dann die CALLs.

Zack, so einfach ist FORTH.


Ein weiteres wichtiges Wortpaar ist CODE ... END-CODE das macht im Prinzip
das gleiche wie : ... ; aber eben in Assembler, das ist dann für Kenner
und Könner.

Der Anwender wird CODE END-CODE kaum brauchen, das mach dann ggf. ich oder
ein anderer Kenner.

Der Kunde schickt mir nur seine Latte von neuen :- Definitionen und sagt,
funzt alles, aber zu langsam, muss 3x schneller ablaufen. Ich frickel dann
interaktiv raus, wo wie die Zeit verplempert wird und verbessere das oder
schreib das Wort als CODE-Definition. Ist nur ein simples umkodieren, um
den Algorithmus brauch ich mich ja nicht zu kümmern, den hat der Kunde ja
schon als gut befunden. Macht die Sache unglaublich einfach. Meist sind
das nur wenige Stellen, die mit CODE getuned werden müssen. Und zum Test
wird halt eine oder mehrere Testschleifen definiert, wo die :- und die
CODE- Definition beide mit den gleichen Parametern aufgerufen und die
Ergebnisse verglichen werden, wenn abweicht, Schleifenabbruch und
weitersuchen, sonst kommt OK und alles ist womöglich schon ok.

Wer bisher durchgehalten hat: BRAVO nun kommt das ENDE bald




Auch sonstige Parameter standen in der Startup Datei

zB. Hubweg wurde mit der syntax

12,3 inch als Hubweg

festgelegt. Oh heute cm? kein Problem, dann eben

17,3 cm als Hubweg

eintippern, wg. mir erst mal zur Probe interaktiv, dann per editor in die
Start. Ja alle meine Projekte wurden als META Sprache in den jeweiligen
Anwender eigenen Fachsprache geschrieben, wegen mir auch in seiner
Landesprache. Ist praktisch Bestandteil von (Vollausbau) FORTH. Genauso
wie METAkompiler. Wenn ich die Fachsprache des Kunden kapiert habe, bin
ich auch einfacher auf seiner Ebene für Klärungen und ich habe vieles von
ihm zu seinem Nutzen gelernt und wir reden weniger aneinander vorbei.
WIN-WIN



So nun zum Schluss:

Schau mal nach Gforth für Windoof, Linux, Android, MAC oder was weis ich
noch alles. Ist eins der mächtigsten Systeme, das ich kenne.

Ich selber hab fast alles unter LMI PCF und F-PC gemacht. Gibs aber nicht
mehr. Nur für Windoof gibbet auch Win32Forth , auch ziemlich fettes Paket.

So genug für heute.
May the FORTH be with you!




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

 

[Hans-Peter Diettrich]

Am 15.08.2019 um 23:45 schrieb Wolfgang Allinger:

So nun zum Schluss:

Schau mal nach Gforth für Windoof, Linux, Android, MAC oder was weis ich
noch alles. Ist eins der mächtigsten Systeme, das ich kenne.

Ich selber hab fast alles unter LMI PCF und F-PC gemacht. Gibs aber nicht
mehr. Nur für Windoof gibbet auch Win32Forth , auch ziemlich fettes Paket.

Für Spectrum, RT-11, RSX-11M und Windows habe ich auch schon Forth
Systeme geschrieben, kein Problem. Nur hilft die Mächtigkeit wenig, wenn
es um Echtzeit auf einem Mikrocontroller geht, bei dem selbst die
primitiven Worte immer einen indirekten Sprung zum nächsten Wort mit
sich herumschleppen. Bei einem 8-Bit ľC läppert sich der Aufwand für den
Sprung oft zu mehr Code als für das Wort selbst zusammen. Deshalb fand
ich die native Compiler-Lösung interessant, wie sie ja auch bei Java für
ľC benutzt wird. Entwickeln kann man dann mit dem Interpiler, und später
reinrassigen Maschinencode laufen lassen. Bis dahin unterscheidet sich
FORTH kaum von BASIC, was die Laufzeit betrifft.

DoDi

 

[Johannes Bauer]

On 15.08.19 23:45, Wolfgang Allinger wrote:

So nun zum Schluss:

Schau mal nach Gforth fĂźr Windoof, Linux, Android, MAC oder was weis ich
noch alles. Ist eins der mächtigsten Systeme, das ich kenne.

Also vermutlich auch eines der am besten optimiertesten.

Deine Argumente sind, zusammenfassend, etwa:

1. Forth ist "schĂśn" debuggbar
2. Forth ist einfach zu schreiben, weil skriptbar

Das sind beides subjektive und qualitative Argumente. Auf meine Frage im
anderen Thread bezĂźglich der Performance antwortest du ausweichend mit
(ich paraphrasiere) "ich bin schon in Rente" und deswegen kĂśnntest du
das nicht testen.

Ich habe vorher noch nie Forth geschrieben aber innerhalb von einer
Stunde konnte ich ein Benchmark zusammenstellen. Und ich habe auch den
auf Wikipedia präsentierten RC4-Forth Code in C von Hand neu
implementiert und zwar komplett naiv, dem Pseudeocode von Wikipedia
folgende.

Dann Gforth, dass du oben empfohlen hast, als Benchmarking verwendet.
Resultate hier: https://github.com/johndoe31415/forthvsc

Der Performance Hit ist fĂźr den Key Schedule Faktor 316, fĂźr den
Datenstrom Faktor 655. Also im Mittel, sagen wir, Faktor 500 lansgsamer.
Das ist also in etwa so als wenn ich auf dem System A meinen ÂľC mit 16
MHz clocke und auf dem System B denselben Code von 32 kHz Uhrenquarz
laufen lasse. Es sind WELTEN.

Wie man damit also irgendwas kritisches hinkriegen soll ist mir vĂśllig
schleierhaft. Faktor 500 ist jenseits von Gut und BĂśse. Das ist einfach
nur unbenutzbar. Ich kann das Argument ja gut verstehen, dass du die
Sprache schĂśn findest. Ich finde z.B. auch Python echt schĂśn. Aber wĂźrde
ich auf nem ÂľC nie einsetzen, weil man halt genau da Ăźblicherweise die
Performance braucht und nicht im Überfluss hat.

Das ist mir schon immer sehr suspekt, wenn jemand nur Vorteile von
irgendwas anpreist. Nichts, was mir bekannt ist, hat nur Vorteile. Dann
muss man aber halt auch so ehrlich sein und die Nachteile (totale
Gurkenperformance) zugeben, sonst ist es einfach nur Unehrlich.

Viele Grüße,
Johannes

 

[Hans-Peter Diettrich]

Am 16.08.2019 um 20:55 schrieb Johannes Bauer:

Ich habe vorher noch nie Forth geschrieben aber innerhalb von einer
Stunde konnte ich ein Benchmark zusammenstellen. Und ich habe auch den
auf Wikipedia präsentierten RC4-Forth Code in C von Hand neu
implementiert und zwar komplett naiv, dem Pseudeocode von Wikipedia
folgende.

Traue keinem Benschmark den Du nicht selbst gefälscht hast ;-)

Numbercrunching ist wirklich nicht die Domäne von FORTH, und auch nicht
von Mikrocontrollern. So ein Vergleich von Äpfeln und Birnen ist wenig
aussagekräftig. 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.

FĂźr eine pdp-11 habe ich in 10 Minuten ein Testprogramm fĂźr einen
Plattencontroller geschrieben und die ProblemlĂśsung gefunden. Am PC ist
sowas sicher nicht zu schaffen, nicht nur mangels Dokumentation der
Hardware, sondern auch mangels direktem Zugriff darauf. Da hilft sogar
ein RT-OS wenig, wenn es um interaktive Programme und ihre Entwicklung geht.

Wie man damit also irgendwas kritisches hinkriegen soll ist mir vĂśllig
schleierhaft. Faktor 500 ist jenseits von Gut und BĂśse.

Kommt drauf an, welche Geschwindigkeit die Anwendung erfordert. Typische
Controller Programme verbringen ihre Zeit fast nur mit Warten auf
Ereignisse, und reagieren dann mit dem Setzen von ein paar Bits der
Hardware. So läßt sich z.B. eine Mikrowelle oder ein 3D-Drucker mit
einem langsamen 8-Bit Mikrocontroller betreiben, da geht auch mit
500000-facher Rechengeschwindigkeit nicht mehr (Takt:100-1000 +
Maschinencode:5-500).


Aber wenn wir schon bei der Kritik sind: FORTH Programme sind weitgehend
write-only. Wenn ein Entwickler nicht eine saubere Trennlinie zwischen
hartem low-level und flexiblem Anwendungscode zieht, läßt sich
nachträglich kaum noch was ändern. Wenn z.B. eine Änderung am Stack
notwendig wird, und beim Update nur eine Verwendung des Wortes Ăźbersehen
wurde, dann ist ein Crash vorprogrammiert :-(

Oft liegt es aber einfach in der Natur der Controller. Was verdammt
nochmal bedeutet es, wenn das Programm dieses oder jenes Bitmuster in
ein Controlregister schreibt, und was geht mĂśglicherweise an anderer
Stelle schief, wenn ich daran etwas ändere. An dieser Stelle hÜrt dann
aber auch die Übertragbarkeit von jeglichem Code auf, wenn die Hardware
eines anderen Controllers anders funktioniert.

DoDi

 

[Johannes Bauer]

On 16.08.19 22:26, Hans-Peter Diettrich wrote:

Am 16.08.2019 um 20:55 schrieb Johannes Bauer:

Ich habe vorher noch nie Forth geschrieben aber innerhalb von einer
Stunde konnte ich ein Benchmark zusammenstellen. Und ich habe auch den
auf Wikipedia präsentierten RC4-Forth Code in C von Hand neu
implementiert und zwar komplett naiv, dem Pseudeocode von Wikipedia
folgende.

Traue keinem Benschmark den Du nicht selbst gefälscht hast ;-)

Naja, ich kann halt kein Forth. Und das Wikipedia-Beispielprogramm ist
das einzige das ich hatte und es ist auch echt Embedded-tauglich. RC4
ist so klein, dass man ihn einfach runterimplementieren kann.

Das Problem ist, dass wenn die Forth-Advokaten sich nicht die MĂźhe
machen, Testprogramme zu liefern, die weniger Overhead haben (damit man
sehen kĂśnnte wie nah man an C rankommt), dass dann halt jemand wie ich
(der keine Ahnung von Forth hat) das Ăźbernehmen muss. Und dann schaffe
ich halt wenigstens harte Zahlen, wo vorher nur rumgewiesel war. Jeder
ist herzlich eingeladen neue Zahlen zu liefern, aber diese qualitativen
Aussagen gehen mir auf den Keks.

Numbercrunching ist wirklich nicht die Domäne von FORTH, und auch nicht
von Mikrocontrollern. So ein Vergleich von Äpfeln und Birnen ist wenig
aussagekräftig.

WĂźrde ich so nicht sagen. Ich habe in ÂľCs, auch auf 8-Bittern schon
digitale Signalverarbeitung gemacht, Multiply/Accumulate,
Fixpointarithmetik. Da ist RC4 eigentlich gar nicht weit davon entfernt.
Und Krypto mach heutzutage jeder IoT-Controller (das sind allerdings
hauptsächlich Cortex-M3 und hauptsächlich AES-CCM oder AES-GCM). Wenn
die Sprache also fĂźr Krypto ungeeignet ist, ist sie fĂźr moderne
Kommunikation (ßber unvertraute Kanäle) ebenso ungeeignet.

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.

Hm aber Wolfgang behauptete doch immer, dass das angelich den Compiler
schon drin hat, d.h. das wird nicht zur Laufzeit einmal compiliert,
sondern immer interpretiert? Das hatte ich anders verstanden.

FĂźr eine pdp-11 habe ich in 10 Minuten ein Testprogramm fĂźr einen
Plattencontroller geschrieben und die ProblemlĂśsung gefunden. Am PC ist
sowas sicher nicht zu schaffen, nicht nur mangels Dokumentation der
Hardware, sondern auch mangels direktem Zugriff darauf. Da hilft sogar
ein RT-OS wenig, wenn es um interaktive Programme und ihre Entwicklung
geht.

Naja, Fehlersuche kann natßrlich schwierig sein. Aber die Fälle, die mir
sagen wir im letzten Jahr wirklich Kopfzerbrechen gemacht haben, das
waren allesamt welche bei denen kein Debugger, kein
Interpreter-Commandline oder irgendwas mehr hilft, weil das in der
Hardware nebenläufige Probleme (DMA) waren und ich ums verrecken nicht
rausgekriegt hab, was das Problem war. Ich glaube Frank Buss hat mir
damals geholfen und mich auf den richtigen Trichter gebracht.

Wie man damit also irgendwas kritisches hinkriegen soll ist mir vĂśllig
schleierhaft. Faktor 500 ist jenseits von Gut und BĂśse.

Kommt drauf an, welche Geschwindigkeit die Anwendung erfordert. Typische
Controller Programme verbringen ihre Zeit fast nur mit Warten auf
Ereignisse, und reagieren dann mit dem Setzen von ein paar Bits der
Hardware.

Naja, kommt drauf an. Bei einem HMI will ich halt nicht 100ms Warten,
nachdem ich den Knopf gedrĂźckt habe, sondern das soll "instantan" passieren.

> So läßt sich z.B. eine Mikrowelle

Stimmt.

oder ein 3D-Drucker mit
einem langsamen 8-Bit Mikrocontroller betreiben,

Neeeh, im Leben nicht. Schrittgenaue Schrittmotorsteuerung, die dann
auch noch durch ordertliches (x16) Microstepping schwieriger gemacht
wird und bei der die Speed-Ramps ordentlich (Sinus) aussehen ist auf
einem lahmen 8-Bitter nicht zu schaffen, wĂźrde ich sagen. Auf einem
schnellen (16 MHz AVR) eventuell gerade so, wenn du nicht viel anderes
machen musst.

Aber wenn wir schon bei der Kritik sind: FORTH Programme sind weitgehend
write-only. Wenn ein Entwickler nicht eine saubere Trennlinie zwischen
hartem low-level und flexiblem Anwendungscode zieht, läßt sich
nachträglich kaum noch was ändern. Wenn z.B. eine Änderung am Stack
notwendig wird, und beim Update nur eine Verwendung des Wortes Ăźbersehen
wurde, dann ist ein Crash vorprogrammiert :-(

Huh, hartcodierte Memory-Layouts? Lolwut? Wolfgang lobte ja, dass es
keinen Linker gibt bei Forth, aber wenn der Programmierer dann von Hand
linken muss, ne, das muss echt nicht sein.

Oft liegt es aber einfach in der Natur der Controller. Was verdammt
nochmal bedeutet es, wenn das Programm dieses oder jenes Bitmuster in
ein Controlregister schreibt, und was geht mĂśglicherweise an anderer
Stelle schief, wenn ich daran etwas ändere. An dieser Stelle hÜrt dann
aber auch die Übertragbarkeit von jeglichem Code auf, wenn die Hardware
eines anderen Controllers anders funktioniert.

Klar, das gilt aber für alle Programmiersprachen gleichermaßen.

Viele Grüße,
Johannes

 

[Wolfgang Allinger]

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

Am 15.08.2019 um 23:45 schrieb Wolfgang Allinger:

So nun zum Schluss:

Schau mal nach Gforth für Windoof, Linux, Android, MAC oder was weis ich
noch alles. Ist eins der mächtigsten Systeme, das ich kenne.

Ich selber hab fast alles unter LMI PCF und F-PC gemacht. Gibs aber nicht
mehr. Nur für Windoof gibbet auch Win32Forth , auch ziemlich fettes Paket.

Für Spectrum, RT-11, RSX-11M und Windows habe ich auch schon Forth
Systeme geschrieben, kein Problem. Nur hilft die Mächtigkeit wenig, wenn
es um Echtzeit auf einem Mikrocontroller geht, bei dem selbst die
primitiven Worte immer einen indirekten Sprung zum nächsten Wort mit
sich herumschleppen. Bei einem 8-Bit ľC läppert sich der Aufwand für den
Sprung oft zu mehr Code als für das Wort selbst zusammen. Deshalb fand
ich die native Compiler-Lösung interessant, wie sie ja auch bei Java für
ľC benutzt wird. Entwickeln kann man dann mit dem Interpiler, und später
reinrassigen Maschinencode laufen lassen.

Bis dahin unterscheidet sich
FORTH kaum von BASIC, was die Laufzeit betrifft.

Nö, IIRC FORTH ist locker Faktor 10 schneller.

Ich hab für 8051&Co harte Echtzeit gemacht.
Das größte war mal mit 16 RTX2000, von denen jeder 16 8051 ersetzte, also
256 8051 Equivalent für 256 Kanäle. RTX2000 weil ich hatte mich geweigert
mehr als 64 8051 gleichzeitig zu hüten. Kann man machen, muss man aber
nicht.

Die Anlage wurde dann nochmal in 3facher Ausfertigung gebaut, also 768
Kanäle für eine US Rohrprüfanlage ohne rotierende Prüfkammern.
Jeder Kanal kam mit 20kHz IFF rein, jeweils 16bit Laufzeit und 8bit
Amplitude, latürnich (US) tiefenabhängiger Jitter, desterwegen kamen die
IRs irgendwann asynchron in dem bis 20kHz Grundtakt.

Und nicht ein einziger IR durfte verschlabbert werden.
Prüfdichte 1 Schuss/mm2 bei 1m/s Vorschub. Jeder mm2 in Aussen, Innen,
Längs und Querrichtung, Wanddicke, dazu noch über Laufzeiten die
Excentrizität und die Ovalität vermessen, latürnich im um Bereich, alle
andere wäre langweilig. Die Aussenfehler, bzw. Aussenwandsignale sind
besonders üble Gesellen, die kommen schon im abklingenden Sendeimpuls
zurück.

Nachprüfen war ganz einfach. Nen paar 0,8mm Bohrungen in dem Test-Rohr mit
unterschiedlichen Tiefen, Richtungen und wehe man hat eine Bohrung am Ende
der Anlage nicht mit Farbpistolen angespritzt und markiert.

Der Kunde fands auch nicht lustig, wenn die Compuster mal son ganzes Rohr
komplett lackiert haben. Fehlersuche war etwas stressig

Die Rohre wurden gerne an Rheinmetall geliefert und die mochten absolut
keine Farbe auf den Rohren, nur ihr Testrohr musste in der Farbe des Tages
Tüpfelchen haben.

Überprüfung war auch leicht, vor und nach jeder Schicht/Los wurde das
Testrohr aufgelegt, und wehe das Farbmuster hat sich verändert.



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 16 Aug 19 at group /de/sci/electronics in article qj6u7q$3mr$1@news2.open-news-network.org
<dfnsonfsduifb@gmx.de> (Johannes Bauer) wrote:

On 15.08.19 23:45, Wolfgang Allinger wrote:

So nun zum Schluss:

Schau mal nach Gforth für Windoof, Linux, Android, MAC oder was weis ich
noch alles. Ist eins der mächtigsten Systeme, das ich kenne.

Also vermutlich auch eines der am besten optimiertesten.

Deine Argumente sind, zusammenfassend, etwa:

1. Forth ist "schön" debuggbar
2. Forth ist einfach zu schreiben, weil skriptbar

Das sind beides subjektive und qualitative Argumente. Auf meine Frage im
anderen Thread bezüglich der Performance antwortest du ausweichend mit
(ich paraphrasiere) "ich bin schon in Rente" und deswegen könntest du
das nicht testen.

Ich habe vorher noch nie Forth geschrieben aber innerhalb von einer
Stunde konnte ich ein Benchmark zusammenstellen. Und ich habe auch den
auf Wikipedia präsentierten RC4-Forth Code in C von Hand neu
implementiert und zwar komplett naiv, dem Pseudeocode von Wikipedia
folgende.

Dann Gforth, dass du oben empfohlen hast, als Benchmarking verwendet.
Resultate hier: https://github.com/johndoe31415/forthvsc

Der Performance Hit ist für den Key Schedule Faktor 316, für den
Datenstrom Faktor 655. Also im Mittel, sagen wir, Faktor 500 lansgsamer.
Das ist also in etwa so als wenn ich auf dem System A meinen ľC mit 16
MHz clocke und auf dem System B denselben Code von 32 kHz Uhrenquarz
laufen lasse. Es sind WELTEN.

Wie man damit also irgendwas kritisches hinkriegen soll ist mir völlig
schleierhaft. Faktor 500 ist jenseits von Gut und Böse. Das ist einfach
nur unbenutzbar. Ich kann das Argument ja gut verstehen, dass du die
Sprache schön findest. Ich finde z.B. auch Python echt schön. Aber würde
ich auf nem ľC nie einsetzen, weil man halt genau da üblicherweise die
Performance braucht und nicht im Überfluss hat.

Das ist mir schon immer sehr suspekt, wenn jemand nur Vorteile von
irgendwas anpreist. Nichts, was mir bekannt ist, hat nur Vorteile. Dann
muss man aber halt auch so ehrlich sein und die Nachteile (totale
Gurkenperformance) zugeben, sonst ist es einfach nur Unehrlich.

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.

BTW Forth Rechner sitzen auch in den Zündern von Granaten, ganz sicher
nicht, weil sie sooo langsame Echt Zeit sind und halten beim start über
30.000g aus. Auch Flugabwehrraketen werden mit Forth in Echtzeit autonom
nachgesteuert. Rechne mal nach, wie genau man da alles erfassen muss,
wenn bei Ankunft das programmierte Ende der SW auf 2m+-20cm genau
eingehalten werden muss. Ja Luftdruck, Temperatur und noch so ein paar
andere Werte müssen dazu auch noch in Echtzeit verwurstet werden.

Es kommst mir so vor, wie ein Oberprimaner, der einer alten Bahnhofnutte
das vögeln erklären will. Ja die Bahnhofnutte nehme ich :>

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.


Ich hab dann später auch oft C166 genommen, die waren etwa 1/3 langsamer,
holten das aber locker mit ihrer tollen Peripherie gegenüber dem RTX auf.
Ah ich vergass, die C166 mussten die Forth engine erst noch beigebogen
bekommen. Auch kein Akt.





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 16 Aug 19 at group /de/sci/electronics in article qj74pm$8ki$1@news2.open-news-network.org
<dfnsonfsduifb@gmx.de> (Johannes Bauer) wrote:

On 16.08.19 22:26, Hans-Peter Diettrich wrote:
Am 16.08.2019 um 20:55 schrieb Johannes Bauer:

Ich habe vorher noch nie Forth geschrieben aber innerhalb von einer
Stunde konnte ich ein Benchmark zusammenstellen. Und ich habe auch den
auf Wikipedia präsentierten RC4-Forth Code in C von Hand neu
implementiert und zwar komplett naiv, dem Pseudeocode von Wikipedia
folgende.

Na immerhin haste innerhalb 1 Stunde Forth schon bedienen können.
Erinner Dich, wie lange haste dafür in anderen Spreachen gebraucht?

Traue keinem Benschmark den Du nicht selbst gefälscht hast ;-)
[...]
Numbercrunching ist wirklich nicht die Domäne von FORTH, und auch nicht
von Mikrocontrollern. So ein Vergleich von Äpfeln und Birnen ist wenig
aussagekräftig.

[...]

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!

Hm aber Wolfgang behauptete doch immer, dass das angelich den Compiler
schon drin hat, d.h. das wird nicht zur Laufzeit einmal compiliert,
sondern immer interpretiert? Das hatte ich anders verstanden.

Für eine pdp-11 habe ich in 10 Minuten ein Testprogramm für einen
Plattencontroller geschrieben und die Problemlösung gefunden. Am PC ist
sowas sicher nicht zu schaffen, nicht nur mangels Dokumentation der
Hardware, sondern auch mangels direktem Zugriff darauf. Da hilft sogar
ein RT-OS wenig, wenn es um interaktive Programme und ihre Entwicklung
geht.

Aber wenn wir schon bei der Kritik sind: FORTH Programme sind weitgehend
write-only. Wenn ein Entwickler nicht eine saubere Trennlinie zwischen
hartem low-level und flexiblem Anwendungscode zieht,

Ja auch in FORTH kann man schlechte Programme schreiben, geht sogar viel
schneller.

läßt sich
nachträglich kaum noch was ändern. Wenn z.B. eine Änderung am Stack
notwendig wird, und beim Update nur eine Verwendung des Wortes übersehen
wurde, dann ist ein Crash vorprogrammiert :-(

Nebulös was Du hier beschreibst. Wer an Primitives rumpfuscht ist selber
Schuld. Und wer keine klare Trennung zwischen HW und Anwendung hinkriegt,
auch. Ich hab mal während einer Entwicklung komplett eine andere CPU samt
Motherboard ausgewechselt, ohne dass die 2 anderen Programmierer irgendwas
in ihren Anwendungsprogrammen und der Bedieneroberfläche ändern musten
oder gar Probleme hatten. Ausser dass das ganze dann viel schneller lief.

Ich hab den Kern und die IR angepasst und gut wars.

Huh, hartcodierte Memory-Layouts? Lolwut? Wolfgang lobte ja, dass es
keinen Linker gibt bei Forth, aber wenn der Programmierer dann von Hand
linken muss, ne, das muss echt nicht sein.

Forth hat keinen Linker und braucht auch keinen. Ein Riesen Vorteil.

Oft liegt es aber einfach in der Natur der Controller. Was verdammt
nochmal bedeutet es, wenn das Programm dieses oder jenes Bitmuster in
ein Controlregister schreibt, und was geht möglicherweise an anderer
Stelle schief, wenn ich daran etwas ändere. An dieser Stelle hört dann
aber auch die Übertragbarkeit von jeglichem Code auf, wenn die Hardware
eines anderen Controllers anders funktioniert.

Klar, das gilt aber für alle Programmiersprachen gleichermaßen.

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 17.08.19 05:34, Wolfgang Allinger wrote:

Na immerhin haste innerhalb 1 Stunde Forth schon bedienen kĂśnnen.
Erinner Dich, wie lange haste dafĂźr in anderen Spreachen gebraucht?

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.

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

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!

Okay, dann hat sogar "kompiliertes" Forth eine Performance-Penalty
Faktor 500. Das ist also NOCH Ăźbler als Hans-Peter dachte?

> Ich hab den Kern und die IR angepasst und gut wars.

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

Huh, hartcodierte Memory-Layouts? Lolwut? Wolfgang lobte ja, dass es
keinen Linker gibt bei Forth, aber wenn der Programmierer dann von Hand
linken muss, ne, das muss echt nicht sein.

Forth hat keinen Linker und braucht auch keinen. Ein Riesen Vorteil.

Ohne Linker ist offenbar 500 Mal besser als mit.

Gruß,
Johannes

 

[Johannes Bauer]

On 17.08.19 05:13, Wolfgang Allinger wrote:

Das ist mir schon immer sehr suspekt, wenn jemand nur Vorteile von
irgendwas anpreist. Nichts, was mir bekannt ist, hat nur Vorteile. Dann
muss man aber halt auch so ehrlich sein und die Nachteile (totale
Gurkenperformance) zugeben, sonst ist es einfach nur Unehrlich.

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.

BTW Forth Rechner sitzen auch in den ZĂźndern von Granaten, ganz sicher
nicht, weil sie sooo langsame Echt Zeit sind und halten beim start Ăźber
30.000g aus. Auch Flugabwehrraketen werden mit Forth in Echtzeit autonom
nachgesteuert. Rechne mal nach, wie genau man da alles erfassen muss,
wenn bei Ankunft das programmierte Ende der SW auf 2m+-20cm genau
eingehalten werden muss. Ja Luftdruck, Temperatur und noch so ein paar
andere Werte mĂźssen dazu auch noch in Echtzeit verwurstet werden.

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.

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.

Es kommst mir so vor, wie ein Oberprimaner, der einer alten Bahnhofnutte
das vÜgeln erklären will. Ja die Bahnhofnutte nehme ich :

Ein Oberprimaner, der sich für unheimlich schlau hält aber außer
Anekdoten keinerlei Evidenz liefern kann oder will. Und dann ins
Rumstammeln kommt und wĂźtend wird, wenn sogar die Bahnhofsnutte in der
Lage ist, seine zusammengelogenen Behauptungen mal zu ĂźberprĂźfen.

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 dann später auch oft C166 genommen, die waren etwa 1/3 langsamer,
holten das aber locker mit ihrer tollen Peripherie gegenĂźber dem RTX auf.
Ah ich vergass, die C166 mussten die Forth engine erst noch beigebogen
bekommen. Auch kein Akt.

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

Gruß,
Johannes

 

[Hans-Peter Diettrich]

Am 17.08.2019 um 08:27 schrieb Johannes Bauer:

Ich hab den Kern und die IR angepasst und gut wars.

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

Das sind nur 20-50 Worte, die portiert werden mĂźssen, der Rest ist der
immer gleiche FORTH Code. Ich habe heute noch den Karteikasten mit den
Implementierungen der Worte zu meinem Lieblingsforth.

Huh, hartcodierte Memory-Layouts? Lolwut? Wolfgang lobte ja, dass es
keinen Linker gibt bei Forth, aber wenn der Programmierer dann von Hand
linken muss, ne, das muss echt nicht sein.

Bei der Eingabe wird die Definition eines jeden Wortes im WĂśrterbuch
gesucht, und entweder dessen Code ausgefĂźhrt oder die Adresse des Codes
abgespeichert. Deshalb muß nachträglich nichts mehr gelinkt werden, das
ist schon passiert.

DoDi

 

[Hans-Peter Diettrich]

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...)
übersetzt. Daneben gibt es noch Compiler, die BASIC, JAVA, FORTH usw. in
echten Maschinencode übersetzen können. Was bei BASIC allerdings nicht
viel bringt, wenn dort ein VARIANT Datentyp verwendet wird - siehe
VisualBasic.

Hm aber Wolfgang behauptete doch immer, dass das angelich den Compiler
schon drin hat, d.h. das wird nicht zur Laufzeit einmal compiliert,
sondern immer interpretiert? Das hatte ich anders verstanden.

FORTH erlaubt Compilierung bei der Eingabe, was aber nicht Compilierung
in Maschinencode bedeutet, und auch nicht unbedingt in anderweitig
optimierten Code. Der Programmierer kann aber vorsehen, daß ein Wort im
IMMEDIATE Mode (bei der Eingabe) normal abgespeichert wird, aber direkt
weiteren FORTH Code erzeugt, wenn es in der abgespeicherten Version
aufgerufen wird. Siehe dazu die eckigen Klammern [ und ]. Das wäre dann
schon eine weitere Stufe der Compilierung. Daneben gibt es natürlich
auch die Erzeugung von Maschinencode, mit Assembler-Einschüben wie in
anderen Compilersprachen. Das Schreiben der FORTH-Assembler für meine
diversen Mikroprozessoren hat mir viel Spaß gemacht, da man sich dank
UPN kaum um irgendwelche spezielle Syntax Gedanken machen muß, der
Parser wird ja von FORTH geliefert.

läßt sich
nachträglich kaum noch was ändern. Wenn z.B. eine Änderung am Stack
notwendig wird, und beim Update nur eine Verwendung des Wortes übersehen
wurde, dann ist ein Crash vorprogrammiert :-(

Nebulös was Du hier beschreibst.

Schau Dir mal die Stack-Beschreibung an, die zu jedem Wort angegeben
sein muß. Wenn daran etwas geändert werden muß, hat das einen ganzen
Rattenschwanz von weiteren Änderungen zur Folge. HLL Compiler merken es
normalerweise, wenn Parameterlisten geändert werden, bei FORTH ist mir
so ein Mechanismus nicht bekannt.

Wer an Primitives rumpfuscht ist selber
Schuld. Und wer keine klare Trennung zwischen HW und Anwendung hinkriegt,
auch. Ich hab mal während einer Entwicklung komplett eine andere CPU samt
Motherboard ausgewechselt, ohne dass die 2 anderen Programmierer irgendwas
in ihren Anwendungsprogrammen und der Bedieneroberfläche ändern musten
oder gar Probleme hatten. Ausser dass das ganze dann viel schneller lief.

Ich hab den Kern und die IR angepasst und gut wars.

Ich habe mir seinerzeit etliche Bibliotheken angeschaut, die ohne
umfangreiche Beschreibung schlicht unbrauchbar waren. Möglicherweise gab
es so eine Dokumentation, aber wenn die nicht auf den Disketten
mitgeliefert wurde, war man in der Zeit vor dem Internet mit dem
Quelltext alleine einfach nur aufgeschmissen :-(

DoDi

 

[Hans-Peter Diettrich]

Am 16.08.2019 um 22:47 schrieb Johannes Bauer:

On 16.08.19 22:26, Hans-Peter Diettrich wrote:

Numbercrunching ist wirklich nicht die Domäne von FORTH, und auch nicht
von Mikrocontrollern. So ein Vergleich von Äpfeln und Birnen ist wenig
aussagekräftig.

WĂźrde ich so nicht sagen. Ich habe in ÂľCs, auch auf 8-Bittern schon
digitale Signalverarbeitung gemacht, Multiply/Accumulate,
Fixpointarithmetik. Da ist RC4 eigentlich gar nicht weit davon entfernt.

Da war die Arithmetik aber sicher nicht mit den FORTH Primitives
implementiert. Wenn schon die Grundrechenarten wegen der Fädeltechnik
ein Vielfaches an Rechenzeit gegenĂźber Maschinencode kosten, kann man
von darauf aufbauender Fädelei keine bessere Performance erwarten.

Wie man damit also irgendwas kritisches hinkriegen soll ist mir vĂśllig
schleierhaft. Faktor 500 ist jenseits von Gut und BĂśse.

Kommt drauf an, welche Geschwindigkeit die Anwendung erfordert. Typische
Controller Programme verbringen ihre Zeit fast nur mit Warten auf
Ereignisse, und reagieren dann mit dem Setzen von ein paar Bits der
Hardware.

Naja, kommt drauf an. Bei einem HMI will ich halt nicht 100ms Warten,
nachdem ich den Knopf gedrĂźckt habe, sondern das soll "instantan" passieren.

HMI?

Schlechtes Beispiel, wenn das Entprellen eines Knopfes schon 10-20ms
kostet, egal wie schnell der Prozessor oder die Programmiersprache ist.
Und auf Interrupts kann man auch in FORTH direkt reagieren, wieso nicht?

So läßt sich z.B. eine Mikrowelle

Stimmt.

oder ein 3D-Drucker mit
einem langsamen 8-Bit Mikrocontroller betreiben,

Neeeh, im Leben nicht. Schrittgenaue Schrittmotorsteuerung, die dann
auch noch durch ordertliches (x16) Microstepping schwieriger gemacht
wird und bei der die Speed-Ramps ordentlich (Sinus) aussehen ist auf
einem lahmen 8-Bitter nicht zu schaffen, wĂźrde ich sagen. Auf einem
schnellen (16 MHz AVR) eventuell gerade so,

16MHz *ist* fĂźr mich langsam.

> wenn du nicht viel anderes machen musst.

Mehr muß man beim Drucken auch nicht.

Geht Microstepping Ăźberhaupt vernĂźnftig in Software, bzw. warum sollte
man das so machen? Motortreiber braucht man sowieso, und die gibt es
passend mit Microstepping, Strombegrenzung etc.


DoDi

 

[Ewald Pfau]

Johannes Bauer <dfnsonfsduifb@gmx.de>:

Hm aber Wolfgang behauptete doch immer, dass das angelich den Compiler
schon drin hat, d.h. das wird nicht zur Laufzeit einmal compiliert,
sondern immer interpretiert? Das hatte ich anders verstanden.

Interpretiert wird in mehreren Schichten. Der äußere Interpreter hat seit
ANS/ISO-Forth vier definierte Dauerschleifen dafĂźr, als letzter Fallback
dann das QUIT (das heißt so), das als Dauerschleife von der Tastatur
entgegennimmt, im Fehlerfall ein Standard-THROW exekutiert, als ABORT, womit
alle Schachtelungen aufgehoben werden und der Text-Interpreter wieder neu
beginnt.

INCLUDED nimmt Text aus einer zeilenorientierten Datei entgegen. THRU macht
dasselbe mit dem Block-Mechanismus, der Ăźberlebt hat, um Massenspeicher
festverdrahtet in 1k-BlĂścken durchnumeriert ansprechen zu kĂśnnen.

Und dann, äh (hab schon länger nichts mehr damit gemacht), nochmal dasselbe
mit einer Zeile, die als String-Parameter gegeben wird.

Soweit der äußere Interpreter.

Eine Schicht darunter wird man eher von Code reden, da nicht mehr Textfolgen
abgearbeitet werden, sondern kompilierte Folgen im Speicher. Dass dennoch
das Wort Interpreter ins Spiel kommt, liegt daran, dass die Modelle, wie
kompiliert wurde, transparent mitgeteilt werden kĂśnnen. Bzw. war das Sitte
zu der Zeit etwa bis MItte der 1990er, dem kundigen Nutzer das mitzuteilen,
wie die Schacthelung von Code im Speicher organisiert ist.

Nunmehr ist der kundige Nutzer auch nurmehr ein braver Konsument und fragt
nicht mehr nach so etwas, bzw. ist eher irritiert.

Aber gut, die Vokabel P-Code war ßber den Forth-Horizont hinaus geläufig,
die das korrespondiert, dass der Code aus einer Abfolge von Tokens besteht.
Und die Tokens, wenn sie zur Abarbeitung angesprungen werden, sind dann
wiederum Abfolgen von Tokens.

Erst die unterste Schicht von Tokens sind dann in Assembler kodiert.

Noch in den Forth-79 und -83 wurde das fein kultiviert, mitzuteilen, auf
welche Art die Tokens angesprungen wurden. Im kompaktesten Fall besteht
selbst noch der Beginn eines Tokens aus einem Verweis auf ein Token, dem die
Kette der folgenden Tokens mitgeteilt wird, und startet den Mechanismus des
Schachtelns und Weiterschaltens (typischerweise ein kleines Code-Schnipsel,
mit dem Namen NEXT).

Das ist die kompakteste und dann auch zugleich langsamste Form, wie der Code
repräsentiert und zum Laufen gebracht werden kann. Wenn man die
Hardware-Architektur vor sich hat, wo der letztliche Assmember strikt
Read-Only ist, und man aber ad hoc dazukompilieren will kĂśnnen, dann ist das
zugleich die einzige MĂśglichkeit, eine etwas universellere Maschine zu
implementieren. Die kann dann, mit ein wenig Forth-Assembler-Code im ROM,
rein vom RAM laufen.

Die macht dann zwar alles. Und braucht dann aber viel Geduld. FĂźr uCs ist
das eher eine akademische Übung. Oder der Teil von Entwicklerei, wo eben das
minimale Forth-Assembler im ROM als Maschinen-Monitor dient, mittels dem per
ad hoc dazukompilierten Routinen die Maschine auf ihr Befinden hin abfragt
werden kann. Das geht dann ohne Emulatoren, weil man von einem sehr frĂźhen
Stadium weg am Objekt selbst modellieren kann, ohne dass man eine Emulation
o.ä. braucht.

Wenn der Zeittakt der Umgebung aber eher in Sekunden misst, ohne Milli oder
Mikro, dann braucht es keinen weiteren Luxus zur Beschleunigung.

Die wenigen Softwarehäuser, die es fßr Forth gibt, unterstßtzen dieses
Modell aber kaum mehr. Dort ist Emulation angesagt, und erweitert wird fĂźr
die kleinen Prozessoren dann im emulierten ROM per Assembler-kompiliertem
Forth.

Letzteres ist dan schon die dritte Variante des Interpretierens von
Assembler-Code auf Maschinenebene, indem eben der Compiler alles, was im
Compiler-Modus anfällt, als Kette von Assembler-Code ablegt. Je nach Grad
der Optimierungen die man sich antut, wird dann jedes StĂźck Code, das ein
Token hätte sein kÜnnen, nun aber in Assembler dasteht, mehr oder weniger
schlau mit dem Code zuvor und danach verkettet. Es muss ja weiterhin die
Kompatibilität aufrecht bleiben wie von diesem Code aus tiefere Ebenen der
Verschachtelung erreicht werden.

Die zweite Zwischenvariante fĂźr den Address-Interpreter, mit dem Code
abgearbeitet wird, statt Flließtext, besteht darin, dass er Beginn eines
Tokens nicht selbst wiederum einen Zeiger auf das Token verweist, mit dem
Verschachtelung und Weiterschalten im Code organisiert ist, sondern diese
kleine Standard-Routine steht dann in Assembler zu Beginn von jedem Token.

Das erste war also die indirekt gefädelte (threaded) Variante, das zweite
die direkt gefädelte und das dritte der Inline-Code.

Und Ăźber allem thront dann das Hirnschmalz, das in Optimierungen gesteckt
wird. Oder auch nicht. Aus letzterem wird zwar auch eine lustige Maschine,
aber viel machen kann man damit nicht wirklich, oder nur bei ausnehmend
gemĂźtlichen Anwendungen.

***

Huh, hartcodierte Memory-Layouts? Lolwut? Wolfgang lobte ja, dass es
keinen Linker gibt bei Forth, aber wenn der Programmierer dann von Hand
linken muss, ne, das muss echt nicht sein.

Zum einen: In Forth wird er flinke Turnaround unterstĂźtzt, um Bottom-Up
sekundenschnell austesten, ändern wieder testen, usw. zu kÜnnen. Zugleich
wird angenommen dass jemand der mit dieser Maschine arbeitet, genug
Selbstdisziplin mitbringt, dass er sich nicht ständig selbst Fallen stellt.
Man baut also eher ein GerĂźst aus gut belastbaren weil ausgetesteten
Routinen auf, und deren Schnittstellen sollten dann doch wohl auch weiterhin
stabil bleiben. Wer dann nachher an den Schnittstellen herumdreht, bzw. das
dann nicht im Griff hat, wenn er es trotzden macht, dem ist dann wohl nicht
zu helfen. Es gibt da keinen reichen Onkel, als wie ein solcher sich die
Riesenkompiler des Mainstream darstellen. Wenn man etwas ad hoc ĂźberprĂźft
wissen will, muss man das selber einbauen. DafĂźr geht das dann leicht und
locker dahin.

DarĂźberhinaus: Indem die meiste Zeit der Blick auf den Text-Interpreter im
Vordergrund stand, hat sich fĂźr Forth die Kultur des Austauschs von
kompiliertem Code nicht entwickelt. Das ist keine Frage des Systems sondern
der Historie. Man kann das auch in Fortg einbauen, dass es kompilierten Code
als Schnipsel nachlädt.

Das Modell des Open-Boot-Systems hat dann die Tokens normiert ... was ebenso
fĂźr ein System gilt, das auf den Einsatz von Chipkarten hin gestrickt wurde,
mit dem Handling von APDUs im Mittelpunkt, wie mit der ISO 7816 begonnen,
läuft als ISO 20060 unter dem Kßrzel OTA - Open Terminal Architecture (jaja,
damit hab ich mich fĂźr eine ziemliche Zeit herumgeschlagen).

Wenn dann Folgen von Tokens ausgetauscht werden, ist man bereits auf
Code-Ebene, sodass gleich der Adress-Intrerpreter mit Code gefĂźttert wird,
und nicht der äußere Interpreter mit Quelltext.

Und das ist dann schon die Schicht, wie Libraries gestrickt sind.

Man muss, abseits des Mainstreams, die Bedeutung etwas grĂźndlicher
abklopfen, was denn gemeint ist, wenn Libraries ausgetauscht werden. Die
Architekturen sind weniger technisch als auch historisch bedingt.

Wenn es darum ginge, sich des Mainstreams zu bedienen, wo massenweise die
Code-Fragmente und die Headerfiles herumgurken, dann gibt es zur Übernahme
in Forth eine harte Klippe, das ist die Konstruktion des Aufbaus mit
prinzipiell zwei Stacks, und nicht nur einem - der Stack fĂźr die
Verschachtelung, und der Stack fĂźr die Datenweitergabe.

Auch das ist wohl nur historisch bedingt - wahrscheinlich auf die
Denkfaulheit beim Umgang mit der Vokabel Der-Stack! zurßckzufßhren. Hätte
das Personal zu seiner Zeit etwas stringenter in analytischen Dimensionen
gedacht, wäre eine Architektur mit zwei Stapeln fßr die rein technisch
bedingten Erfordernisse viel naheliegender.

Der Vorteil, den Forth in dieser Hinsicht hat, ist immens, als da
Verschachtelungen viel bililiger zu haben sind, wenn nicht bei jedem Sprung
im Code zugleich der Zusanmenhang der Daten zwuschengesichert werden muss.
Das erspart man sich, wenn die Parameter transparent auf einem gemeinsamen
Stack durchgereicht werden. Von daher wurde typischerweise in Forth stets
mit kleinen Routinen kodiert, mit den anonymen Parametern auf dem Stack.

Forth und C haben zu einer Zeit schon koĂŤxistiert, als noch nicht so krass
klar war, dass C zum Mainstream wĂźrde. Da hat vor allem die Industrie
nachgeholfen, indem mit FĂśrderpaketen letzteres tapfer gepampert wurde,
parallel dazu, dass Unix-Maschinen sich verbreiteten. C verbreitete sich
erst einmal ganz spezifisch mit letzteren - aber auch ist hier die Tradition
aufrecht geblieben, dass, auch in C, Quelltexte korrespondiert werden, es
mĂźssen nicht kompilierte Libraries sein, was in Umlauf kommt.

Das Interesse, dass nur kompilierte Libraries im Umlauf sind, ist eher
merkantiler Natur, in der Hoffnung, ProblemlĂśsungen fĂźr alles und jedes als
uneinsehbaren kryptischen Datenhaufen in Plastik zu verpacken und teuer
verkaufen zu kĂśnnen. Mit Quelltext geht das nicht so locker. Dank der
Bewegung fĂźr offen zu verbreitende Software ist doch letzteres als
eigentlich vernĂźnftigere Ansicht um die Welt geschwappt.

Das war der Punkt, wo Anfang der 1990er ein Team fĂźr das ANSI eine
Normierung auskungelte, von allzu konkreten Implementierungsdetails Abschied
zu nehmen und abstraktere Prinzipien stattdessen aufzunehmen, sodass unter
diesem Titel dann Quelltext austauschbar wĂźrde - 1998 wurde ein ISO daraus.

 

[Johannes Bauer]

On 17.08.19 09:44, Hans-Peter Diettrich wrote:

Naja, kommt drauf an. Bei einem HMI will ich halt nicht 100ms Warten,
nachdem ich den Knopf gedrĂźckt habe, sondern das soll "instantan"
passieren.

HMI?

Schlechtes Beispiel, wenn das Entprellen eines Knopfes schon 10-20ms
kostet, egal wie schnell der Prozessor oder die Programmiersprache ist.
Und auf Interrupts kann man auch in FORTH direkt reagieren, wieso nicht?

Ist eben genau ein gutes Beispiel: Das Entprellen dauert schon die
meiste Zeit, die ist schon mal von der Reaktion fix weg. Da wĂźrde ich
auch schon eher 50-75ms ansetzen. Und dann willst du dem Benutzer
*sofort* signalisieren, was passiert ist.

Wenn du da ein LCD oder sowas dran hast, das bissl mehr braucht als nur
GPIO LED an/aus, dann merkst du das sehrwohl. Und es gibt genug
Implementierungen die da extrem träge/ätzend sind.

So läßt sich z.B. eine Mikrowelle

Stimmt.

oder ein 3D-Drucker mit
einem langsamen 8-Bit Mikrocontroller betreiben,

Neeeh, im Leben nicht. Schrittgenaue Schrittmotorsteuerung, die dann
auch noch durch ordertliches (x16) Microstepping schwieriger gemacht
wird und bei der die Speed-Ramps ordentlich (Sinus) aussehen ist auf
einem lahmen 8-Bitter nicht zu schaffen, wĂźrde ich sagen. Auf einem
schnellen (16 MHz AVR) eventuell gerade so,

16MHz *ist* fĂźr mich langsam.

Das ist aber verwĂśhnt. WĂźrde 32 kHz als extrem langsam, 1 MHz als
langsam, 16 MHz als schnell und 48 MHz als superschnell bezeichnen.

wenn du nicht viel anderes  machen musst.

Mehr muß man beim Drucken auch nicht.

Geht Microstepping Ăźberhaupt vernĂźnftig in Software, bzw. warum sollte
man das so machen? Motortreiber braucht man sowieso, und die gibt es
passend mit Microstepping, Strombegrenzung etc.

Motortreiber mit Microstepping machen aber halt nur das, was der Name
vermuten lässt: Den Motor mit Microstepping *treiben*. Steppen musst du
schon noch selber und bei Microstepping eben genau 16x so oft fĂźr
dieselbe Geschwindigkeit.

Da brauchst du also einen ÂľC, der die Steps generiert (und die eben auch
entsprechend des Gewindigkeitsprofils) und dann den Treiber zusätzlich,
das ist kein Ersatz. Beim 3D-Drucker macht das sicher ein ÂľC. Es gibt
dann heutzutage immer Ăśfter recht teuer verkauft sogenannte Closed-Loop
Stepper, die nehmen dir das ab (da ist quasi ein ÂľC + Treiber mit
angeflanscht direkt an den Stepper und der nimmt z.B. via RS232
Kommandos entgegen, die ihn wie einen Servo aussehen lassen).

Gruß,
Johannes

 

[Helmut Schellong]

On 08/16/2019 22:47, Johannes Bauer wrote:

On 16.08.19 22:26, Hans-Peter Diettrich wrote:
Am 16.08.2019 um 20:55 schrieb Johannes Bauer:

Ich habe vorher noch nie Forth geschrieben aber innerhalb von einer
Stunde konnte ich ein Benchmark zusammenstellen. Und ich habe auch den
auf Wikipedia präsentierten RC4-Forth Code in C von Hand neu
implementiert und zwar komplett naiv, dem Pseudeocode von Wikipedia
folgende.

Traue keinem Benschmark den Du nicht selbst gefälscht hast ;-)

Naja, ich kann halt kein Forth. Und das Wikipedia-Beispielprogramm ist
das einzige das ich hatte und es ist auch echt Embedded-tauglich. RC4
ist so klein, dass man ihn einfach runterimplementieren kann.

Das Problem ist, dass wenn die Forth-Advokaten sich nicht die MĂźhe
machen, Testprogramme zu liefern, die weniger Overhead haben (damit man
sehen kĂśnnte wie nah man an C rankommt), dass dann halt jemand wie ich
(der keine Ahnung von Forth hat) das Ăźbernehmen muss. Und dann schaffe
ich halt wenigstens harte Zahlen, wo vorher nur rumgewiesel war. Jeder
ist herzlich eingeladen neue Zahlen zu liefern, aber diese qualitativen
Aussagen gehen mir auf den Keks.

Harte Fakten werden nicht gemocht, weil sie alle 'Optionen' ersticken.

Ich habe auch mal einen Test gemacht, auf ein und derselben Plattform,
mit gleichen Mitteln und Aufgaben auf Software-Ebene.

Ergebnisse des jeweiligen Zeitbedarfs (1996):
C 1
Pascal 5
COBOL 80

C ist nicht zu toppen!
Das bewahrheitet sich immer wieder.


--
Mit freundlichen Grüßen
Helmut Schellong var@schellong.biz
www.schellong.de www.schellong.com www.schellong.biz
http://www.schellong.de/c.htm

 

[Wolfgang Allinger]

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

On 17.08.19 05:34, Wolfgang Allinger wrote:

Na immerhin haste innerhalb 1 Stunde Forth schon bedienen können.
Erinner Dich, wie lange haste dafür in anderen Spreachen gebraucht?

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,

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.

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!

Okay, dann hat sogar "kompiliertes" Forth eine Performance-Penalty
Faktor 500. Das ist also NOCH übler als Hans-Peter dachte?

Ich hab den Kern und die IR angepasst und gut wars.

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?

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. 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?).

Huh, hartcodierte Memory-Layouts? Lolwut? Wolfgang lobte ja, dass es
keinen Linker gibt bei Forth, aber wenn der Programmierer dann von Hand
linken muss, ne, das muss echt nicht sein.

Forth hat keinen Linker und braucht auch keinen. Ein Riesen Vorteil.

Ohne Linker ist offenbar 500 Mal besser als mit.

Keine Ahnung wie Du auf diesen blöden Trip kommst.

Als grobe Faustformeln:

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.
Die größten Kernel, die ich kenne sind BigForth und Gforth. Gforth läuft
überall, wo es C für gibt. Für WIN32 rund 6MB mit allem Schnätterateng.


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.

Einer meiner Kunden hat seine Z80 und 8051 Systeme in der 100DM Klasse
durch 1000DM+ RTX2000 boards ersetzt. Ich hatte Kammerflimmern, als ich
das mitbekam... Ruhig Blut, Herr Allinger, mit FORTH auf einem RTX2000
können meine Programmierer, selbst die Anfänger, garnicht so umständlich
und unoptimiert schreiben, dass er die Aufgabe nicht in 1-3 Tagen fertig
hat. Und die machten da einiges für Steuerung teuerster Werkzeug
Maschinen, kein PillePalle.

Und wegen Positionierung, Rechenzeit, Komplexheit und Deiner hochgeliebten
Schrittmotorsteuerungen: zu meiner Zeit hat KUKA die Roboter mit FORTH
gesteuert. Der Greifarm des Space-Shuttle war auch in FORTH programmiert.
Diverse Satelitten, Lokomotiven bei BR, Flughäfen (nä, nicht BER) und
Shooting Ranges USMC werden auch mit FORTH betrieben. 99% aller FORTH
anwendenden Firmen benutzen es als Betriebsgeheimnis, manchmal auch nicht
so geheimnisvoll: Johannes (!) Reilhofer Getriebe Prüfstände und Delta-
Analysatoren.

Alles Nichtskönner? Alle mögen kein RPN?

Die 1. Anwendung von FORTH war übrinx die Steuerung von astronomischen
Teleskopen. Da mussten die Proggies auf Zuruf von den Astronomen geändert
werden. Das höchste Ziel war damals Transportabilität und schnellste
Anpassung. Mission acomplished.

Für die, die sich ernsthaft für FORTH interessieren und bei RPN nicht
kotzen: Forth-ev.de



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 qj87b7$52q$1@news2.open-news-network.org
<dfnsonfsduifb@gmx.de> (Johannes Bauer) wrote:

On 17.08.19 05:13, Wolfgang Allinger wrote:

Das ist mir schon immer sehr suspekt, wenn jemand nur Vorteile von
irgendwas anpreist. Nichts, was mir bekannt ist, hat nur Vorteile. Dann
muss man aber halt auch so ehrlich sein und die Nachteile (totale
Gurkenperformance) zugeben, sonst ist es einfach nur Unehrlich.

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.

BTW Forth Rechner sitzen auch in den Zündern von Granaten, ganz sicher
nicht, weil sie sooo langsame Echt Zeit sind und halten beim start über
30.000g aus. Auch Flugabwehrraketen werden mit Forth in Echtzeit autonom
nachgesteuert. Rechne mal nach, wie genau man da alles erfassen muss,
wenn bei Ankunft das programmierte Ende der SW auf 2m+-20cm genau
eingehalten werden muss. Ja Luftdruck, Temperatur und noch so ein paar
andere Werte müssen dazu auch noch in Echtzeit verwurstet werden.

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?

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!

Es kommst mir so vor, wie ein Oberprimaner, der einer alten Bahnhofnutte
das vögeln erklären will. Ja die Bahnhofnutte nehme ich :

Ein Oberprimaner, der sich für unheimlich schlau hält aber außer
Anekdoten keinerlei Evidenz liefern kann oder will. Und dann ins
Rumstammeln kommt und wütend wird, wenn sogar die Bahnhofsnutte in der
Lage ist, seine zusammengelogenen Behauptungen mal zu überprüfen.

Nänä Bahnhofsnutte hab ich schon gewählt, nicht das Wort im Munde
rumdrehen!

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!

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

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

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.

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.

Es wurde seinerzeit gemunkelt, dass die Patriots auch mit RTX2000 flogen,
aber hab das nie verifizieren können. NDA rulez. Jedenfalls war der Markt
plötzlich leergefegt und RTX wurden in Gold aufgewogen (u.a. wg. RAD-
Hard). Hab da mal die restlichen 10 aus meinem Handlager gut versilbert

Die Honks bei Harris haben alle Entwickler gefeuert und wollten so richtig
Absahnen, als dann der Nachschub klemmte, und die Entwickler in aller Welt
gute neue Jobs hatten, war es für Harris zu spät. Keine Ahnung, obs Harris
noch gibt. Gier frisst Hirn!

Ich hab dann später auch oft C166 genommen, die waren etwa 1/3 langsamer,
holten das aber locker mit ihrer tollen Peripherie gegenüber dem RTX auf.
Ah ich vergass, die C166 mussten die Forth engine erst noch beigebogen
bekommen. Auch kein Akt.

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 hast Du an dem Begriff "erstellen eines Target für eine NEUE CPU"
nicht verstanden?



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 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!

übersetzt. Daneben gibt es noch Compiler, die BASIC, JAVA, FORTH usw. in
echten Maschinencode übersetzen können.

Bei FORTH die sog. META Compiler.

Was bei BASIC allerdings nicht
viel bringt, wenn dort ein VARIANT Datentyp verwendet wird - siehe
VisualBasic.

Hm aber Wolfgang behauptete doch immer, dass das angelich den Compiler
schon drin hat, d.h. das wird nicht zur Laufzeit einmal compiliert,
sondern immer interpretiert? Das hatte ich anders verstanden.

FORTH erlaubt Compilierung bei der Eingabe, was aber nicht Compilierung
in Maschinencode bedeutet, und auch nicht unbedingt in anderweitig
optimierten Code.

Das eine sind die COLON (HLL) Definitionen, das andere die CODE (ASM)
Teile.

Der Programmierer kann aber vorsehen, daß ein Wort im
IMMEDIATE Mode (bei der Eingabe) normal abgespeichert wird, aber direkt
weiteren FORTH Code erzeugt, wenn es in der abgespeicherten Version
aufgerufen wird. Siehe dazu die eckigen Klammern [ und ]. Das wäre dann
schon eine weitere Stufe der Compilierung. Daneben gibt es natürlich
auch die Erzeugung von Maschinencode, mit Assembler-Einschüben wie in
anderen Compilersprachen. Das Schreiben der FORTH-Assembler für meine
diversen Mikroprozessoren hat mir viel Spaß gemacht, da man sich dank
UPN kaum um irgendwelche spezielle Syntax Gedanken machen muß, der
Parser wird ja von FORTH geliefert.

So isset, ein Beispiel, u.a. mit IMMEDIATE unten dran gepappt.

Und wem das nicht reicht, es gibt auch noch CREATE DOES> , was
Unterschiede zur Compile und zur Laufzeit macht. Hab ich u.a. gerne
genommen um IR Vectoren aufzusetzen oder etwas ähnliches für mein 'Micker-
Forth' für den 8031 zu machen. BTW auch die berühmten ARRAY Definitionen
sind elegant mit CREATE DOES> .

läßt sich
nachträglich kaum noch was ändern. Wenn z.B. eine Änderung am Stack
notwendig wird, und beim Update nur eine Verwendung des Wortes übersehen
wurde, dann ist ein Crash vorprogrammiert :-(

Nebulös was Du hier beschreibst.

Schau Dir mal die Stack-Beschreibung an, die zu jedem Wort angegeben
sein muß. Wenn daran etwas geändert werden muß, hat das einen ganzen
Rattenschwanz von weiteren Änderungen zur Folge. HLL Compiler merken es
normalerweise, wenn Parameterlisten geändert werden, bei FORTH ist mir
so ein Mechanismus nicht bekannt.

Hab nie erlebt, dass man an einer Stack Reihenfolge was ändern musste.
Kann mir auch keinen Reim drauf machen.

Wenn irgendwer halt ne andere Reihenfolge oder Menge braucht, soll er hat
ein neues Wort definieren, dann crasht nix.

Doof ist allerdings, wer die Warnung "... is redifined" in den Wind
schlägt. Aber wers braucht, kanns haben.

Dummrumpatchen im Kernel geht auch äusserst einfach, der Erfolg ist meist
sofort sichtbar.

Ich habe mir seinerzeit etliche Bibliotheken angeschaut, die ohne
umfangreiche Beschreibung schlicht unbrauchbar waren. Möglicherweise gab
es so eine Dokumentation, aber wenn die nicht auf den Disketten
mitgeliefert wurde, war man in der Zeit vor dem Internet mit dem
Quelltext alleine einfach nur aufgeschmissen :-(

Ich hab nie behauptet, dass alle FORTH Programme oder Programmierer gut
waren. Im Gegenteil, auch Stümper konnten Programme zum laufen bringen

Hier mal ein Beispiel für (m)ein IMHO gut dokumentiertes Proggie:
Das ganze Vorgeplänkel dient u.a. der Guten Dokumentation,

Das Dicke Ende, also das interessanteste ist der Abschluss
mit "Feueralarm_bearbeiten", siehe ziemlich letzter Abschnitt.
Ich hoffe, ich habe alle Ümläüte korrekt erwischt und korrodiert

----x8---

\ FEUER Demo FEUERMELDER Anwendung ALL 11:26 14MAY93
\ Last changed screen # 000 ALL 11:26 14MAY93

\ (C) 1993 by Dipl.-Ing. Wolfgang Allinger 'ALL0593'
\ c/o Ingenieurbuero Allinger
\ Brander Weg 6 Tel/FAX: (+49)+212/66811
\ D-42699 Solingen Germany
\ noncommercial use granted !!!

\ Diese lauffähige Demo zeigt, wie eine anwenderfreundliche,
\ selbstdokumentierende Sprache am Beispiel eines FEUERMELDER
\ aussieht. Hinweis: alles in "( )" und nach "\" ist Kommentar.
\ ":" ... ";" sind neue Definitionen.
\ "Feueralarm?" und "Feueralarm_bearbeiten" sind 2!! Programme.
\ Diese Demo belegt weniger als 700 byte Programmspeicher und
\ läuft praktisch auf beliebigen Rechnern ohne Änderung.
\ HISTORY MASTER LOAD SCREEN ALL 11:19 14MAY93

DECIMAL \ default base

000 CONSTANT $VFEUER \ Version Kontrolle

: -FEUER FORGET $VFEUER ; \ entfernt dieses Programm wieder

2 ?SCREENS THRU \ 1 LOAD l"dt dann die Anwendungsbl"cke
\ bei SEQ file system auskommentieren !

\ ALL0593 v0.00 first release




\ .VFEUER ... constants ... USER Interface ALL 10:16 14MAY93

: .VFEUER $VFEUER CR . ; \ zeige Versionsnr.

-1 CONSTANT ja

\ Bereich Meldung .. alle für die jeweilige Umgebung anpassen

VARIABLE Meldung \ bits gesetzt wenns qualmt, n. Zeile setzt
5 Meldung ! \ zB: bit0 = Melder1, bit2 = Melder3
: Melder@ ( a -- u ) @ ; \ liefert Datum aus Adresse
Meldung CONSTANT Melder0 \ liefert Adresse der 1. Meldung
: Rauch ; \ evtl eine Maske.. für geräuchertes
16 CONSTANT bits/Meldung \ zB 16bit oder was auch immer
16 CONSTANT alle \ Anzahl Melder

\ Rauchmelder anwählen abfragen entdeckt? ALL 11:15 14MAY93

VARIABLE Rauchmelder \ 1 ... n

: anwählen ( d a -- ) NIP ( n 0 a -- n a ) ! ;

: abfragen ( a -- uMASKE uDATA )

@ 1- bits/Meldung /MOD ( -- rem qot )
Melder0 + Melder@ ( -- rem uDATA )
1 ROT ( -- uDATA 1 rem )
SHIFT ( -- uDATA uMASKE ) \ rem -> MASKE
SWAP ; ( -- uMASKE uDATA )

: entdeckt? ( uMASKE uDATA -- t=RAUCH) AND 0> ;

\ Feueralarm melden nächsten abgefragt? ALL 11:15 14MAY93

: Feueralarm ( -- ^string nMelder )

" Rauch an Melder Nr.: " ( -- ^string )
Rauchmelder @ ;

: melden ( ^string n -- ) CR SWAP COUNT TYPE . 7 EMIT ;

: nächsten ( -- d ) Rauchmelder @ 1+ 0 ;

: abgefragt? ( n a -- ? ) @ 1- <= ;




\ Feueralarm? ALL 11:02 14MAY93

: Feueralarm? 1. Rauchmelder anwählen
BEGIN
Rauchmelder abfragen
Rauch entdeckt? IF Feueralarm melden THEN
nächsten Rauchmelder anwählen
alle Rauchmelder abgefragt?
ja = UNTIL ;

\ Schlüsselworte GROSS, damits wenigstens noch ein bischen wie
\ Programm aussieht und nicht gleich von jedem verstanden wird!

\ Das ist gemein, aber es kommt noch besser!
\ Der GROSSEN Worte ist genug gewechselt, es folgen Taten!

\ Ab hier wirds gefährlich für Computer-Freaks ALL 11:01 14MAY93

\ Ein paar harmlose(?) Definitionen.. Vorsichtig anschleichen..
: abfragen. abfragen ; : anwählen, anwählen ;
: Falls ; : melden. melden ;
: dann ja = ;
: beginne [COMPILE] BEGIN ; IMMEDIATE
: aufhören [COMPILE] UNTIL ; IMMEDIATE
: ja, [COMPILE] IF ; IMMEDIATE
: Den [COMPILE] THEN ; IMMEDIATE

\ WARNUNG! Gleich haut's Sie möglicherweise vom Schemel,
\ denn nun kommt FORTH rücksichtslos mit seiner ganzen Kraft!!
\ Lassen Sie das nachfolgende bloß nicht Ihren Chef sehen!
\ Nicht weiterlesen, es könnte ein Weltbild zusammenbrechen!!!

\ Feueralarm_bearbeiten ist nun total einfach ALL 11:16 14MAY93

: Feueralarm_bearbeiten 1. Rauchmelder anwählen,
beginne
Rauchmelder abfragen.
Rauch entdeckt? Falls ja, Feueralarm melden.
Den nächsten Rauchmelder anwählen,
alle Rauchmelder abgefragt?
dann aufhören ;

\ Das soll ein Programm sein? Das versteht kein Programmierer!
\ Lieber (*(void(*)())0)() das ist doch wenigstens KERNIGhan.
\ ABER NICHT FÜR MICH und meine Kunden!!!

Feueralarm_bearbeiten \ und so einfach noch sofort zu starten!
\ Aufkleber am Heck: "TSCHÜSS C..."

---x8---


Zum Abschluss:

Ich hab vor einiger Zeit mal ein Info Paket für einen Interessenten hier
zusammengestellt, leider hat der sich das dann wohl nicht angeguckt.

Damit meine Liebesmüh nicht ganz vergeblich ist, wer es auch haben will,
kurze email und ich schicke den Kram.


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 grpsh8FihabU1@mid.individual.net
<anderswo@gmx.net> (Ewald Pfau) wrote:

Johannes Bauer <dfnsonfsduifb@gmx.de>:

Hm aber Wolfgang behauptete doch immer, dass das angelich den Compiler
schon drin hat, d.h. das wird nicht zur Laufzeit einmal compiliert,
sondern immer interpretiert? Das hatte ich anders verstanden.

Interpretiert wird in mehreren Schichten.
[...]

Sehr schöner Beitrag. Danke, Habs gespeichert



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