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

Am 15.08.2019 um 23:45 schrieb Wolfgang Allinger:

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

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:

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

Am 16.08.2019 um 20:55 schrieb Johannes Bauer:

darauf habe ich ja bereits hingewiesen. Schau mal in eine (embedded)

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.

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

einem langsamen 8-Bit Mikrocontroller betreiben, da geht auch mit

Aber wenn wir schon bei der Kritik sind: FORTH Programme sind weitgehend write-only. Wenn ein Entwickler nicht eine saubere Trennlinie zwischen

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

eines anderen Controllers anders funktioniert.

DoDi

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.

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.

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.

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.

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.

Stimmt.

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.

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.

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

Viele Grüße, Johannes

nicht.

Die Anlage wurde dann nochmal in 3facher Ausfertigung gebaut, also 768

Jeder Kanal kam mit 20kHz IFF rein, jeweils 16bit Laufzeit und 8bit

IRs irgendwann asynchron in dem bis 20kHz Grundtakt.

Und nicht ein einziger IR durfte verschlabbert werden.

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

Wolfgang

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

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

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

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!

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

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.

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

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

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.

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

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

Ohne Linker ist offenbar 500 Mal besser als mit.

Gruß, Johannes

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

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.

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.

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.

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

Gruß, Johannes

Am 17.08.2019 um 08:27 schrieb Johannes Bauer:

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.

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

Am 17.08.2019 um 05:34 schrieb Wolfgang Allinger:

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.

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.

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.

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

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.

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?

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

Johannes Bauer :

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

mit einer Zeile, die als String-Parameter gegeben wird.

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

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.

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

Hardware-Architektur vor sich hat, wo der letztliche Assmember strikt

implementieren. Die kann dann, mit ein wenig Forth-Assembler-Code im ROM, rein vom RAM laufen.

minimale Forth-Assembler im ROM als Maschinen-Monitor dient, mittels dem per ad hoc dazukompilierten Routinen die Maschine auf ihr Befinden hin abfragt

Stadium weg am Objekt selbst modellieren kann, ohne dass man eine Emulation

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

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

schlau mit dem Code zuvor und danach verkettet. Es muss ja weiterhin die

Verschachtelung erreicht werden.

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.

wird. Oder auch nicht. Aus letzterem wird zwar auch eine lustige Maschine, aber viel machen kann man damit nicht wirklich, oder nur bei ausnehmend

wird angenommen dass jemand der mit dieser Maschine arbeitet, genug

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

locker dahin.

kompiliertem Code nicht entwickelt. Das ist keine Frage des Systems sondern der Historie. Man kann das auch in Fortg einbauen, dass es kompilierten Code

Das Modell des Open-Boot-Systems hat dann die Tokens normiert ... was ebenso

mit dem Handling von APDUs im Mittelpunkt, wie mit der ISO 7816 begonnen,

Wenn dann Folgen von Tokens ausgetauscht werden, ist man bereits auf

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

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

in Forth eine harte Klippe, das ist die Konstruktion des Aufbaus mit

Auch das ist wohl nur historisch bedingt - wahrscheinlich auf die

das Personal zu seiner Zeit etwas stringenter in analytischen Dimensionen

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.

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

Das Interesse, dass nur kompilierte Libraries im Umlauf sind, ist eher

uneinsehbaren kryptischen Datenhaufen in Plastik zu verpacken und teuer

Normierung auskungelte, von allzu konkreten Implementierungsdetails Abschied zu nehmen und abstraktere Prinzipien stattdessen aufzunehmen, sodass unter

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

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.

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.

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

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

OK> : Hello ." Hello World, hello Johannes" ; Hello <CR>

mit dem <CR> ist es bereits kompiliert und ausgeführt,

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

Spar Dir die Mühe.

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

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.

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

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

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

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!

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

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 :p

Und tut mir leid, dass der RTX2000 keinen Assembler als Maschinencode hat. Nur FORTH :p 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 :o Und ich glaube nicht, dass das eine langsame Anwendung war :p 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!

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

Nein, BASIC interpretiert immer wieder, erst ein BASCOM setzt das als (p-

Bei FORTH die sog. META Compiler.

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

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

sind elegant mit CREATE DOES> .

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

sofort sichtbar.

Ich hab nie behauptet, dass alle FORTH Programme oder Programmierer gut

Das Dicke Ende, also das interessanteste ist der Abschluss mit "Feueralarm_bearbeiten", siehe ziemlich letzter Abschnitt.

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

\ 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

\ HISTORY MASTER LOAD SCREEN ALL 11:19 14MAY93

DECIMAL \ default base

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

\ ALL0593 v0.00 first release

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

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

-1 CONSTANT ja

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

VARIABLE Rauchmelder \ 1 ... n

: 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 ( -- ^string nMelder )

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

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

: abgefragt? ( n a -- ? ) @ 1-

Sehr schöner Beitrag. Danke, Habs gespeichert

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

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.