EFORTH für programmierbaren Rechner

Dies ist der erste Artikel in der 161eForth v0.5b-Reihe, der hier endet: habr.com/en/post/452572

Der EFORTH-Übersetzer ist jetzt auch auf dem inländischen MK-161-Elektronikrechner verfügbar! Am 17. Mai hat Version v0.5b meine Tests sowie fünf TEST-TEST4-Authoring-Tests erfolgreich bestanden. Ich habe erreicht, was allein getan werden kann, aber ich denke, dies ist nur die halbe Miete. Es ist an der Zeit, der Community ein neues Tool vorzustellen, indem der 161eForth-Code für öffentliche Tests geöffnet wird. Ich habe eine Liste, was ich verbessern und wo ich "an Stabilität arbeiten" kann. Ihre Vorschläge und Kommentare werden bei Abschluss der Arbeiten und der Veröffentlichung von Version 1.0 berücksichtigt

Bei der Portierung der neuesten Version von eForth auf die heimische Plattform wurden zwei Hindernisse erfolgreich überwunden - die relativ niedrige Geschwindigkeit der 8-Bit-Maschine, die in ihrer eigenen Eingabesprache programmiert ist, und die bescheidene Menge an verfügbarem Binärspeicher (siehe 2.4.1), nur 4096 Byte.


Beim Schreiben von 161eForth wurden vorgefertigte Lösungen für Callisto, die Eingabesprache der nächsten Generation für inländische PMK, verwendet. Dies ist eine Technologie zur Implementierung einer Fort-Maschine über der dezimalen ALU und der „Harvard“ -Architektur, Konsolentreibern und einem alphanumerischen Tastaturlayout sowie einem darauf basierenden Software-Terminal, das über die serielle RS-232-Schnittstelle betrieben wird. Zusätzlich zu Electronics MK-161 und der 161eForth-Distribution benötigen Sie möglicherweise eine selbstgemachte Patch-Tastatur, auf der die Buchstaben des russischen und englischen Alphabets auf den Tasten signiert sind. Die Buchstaben sind alphabetisch Zeile für Zeile von links nach rechts und von oben nach unten angeordnet.


Dr. Chen-Hanson Ting, Autor moderner Versionen von eForth, betont in seinem Buch [1], wie wichtig es ist, die beiden Komponenten des Forts zu verstehen. Dies ist ein interner ("Adresse") Dolmetscher, mit dem das Gerät den genähten Code von Fort ausführen kann, und ein externer ("Text") Dolmetscher, der für den Dialog mit einer Person verantwortlich ist.

In zwei Artikeln werde ich detailliert auf die radikalsten Lösungen eingehen, die bei der Implementierung jedes dieser beiden Interpreten bei Electronics verwendet werden. Das Erlernen dieser Lösungen kann nützlich und inspirierend sein, um eForth auf andere Geräte mit begrenztem Speicher und begrenzter Leistung zu migrieren. Das Verständnis der Artikel hilft bei einer ersten Einführung in programmierbare Mikrokalkulatoren (PMCs) und Fort. Ich werde schwierige Momente erklären, die nur für Electronics MK und den eForth-Übersetzer gelten.

Zunächst werden die Wörter eForth in allgemein und systemisch unterteilt. Die Größe der Buchstaben ist wichtig. Die Namen gewöhnlicher Wörter werden in Großbuchstaben und in Kleinbuchstaben definiert. Ich habe meine Innovationen auch in eForth in Kleinbuchstaben gemacht. Der Autor von eForth schlägt vor, den Hauptdialog im CAPS-Modus durchzuführen. Wenn Sie das Systemwort verwenden müssen, stellen Sie die Zeit auf Kleinbuchstaben um (FP-Tastenkombination).

In dem Artikel werden alle Wörter in Großbuchstaben geschrieben, um sich vom Text abzuheben. In mehreren frühen eForth-Implementierungen wurden Systemwort-Header ausgeschlossen und nicht vom Befehl WORDS ausgegeben. Dies hat dazu beigetragen, das Erscheinungsbild von eForth zu vereinfachen und die Aufmerksamkeit derjenigen zu sparen, die Fort zum ersten Mal verwenden. In 161eForth wurden die Überschriften dieser Wörter hauptsächlich aufgrund des Vorhandenseins des SEE-Doppelpunkt-Wortdekompilierers gespeichert (siehe Video Nr. 3 am Ende des Artikels), der die Namen von Systemwörtern nicht anzeigt, wenn ihre Überschriften entfernt werden.

Um den Artikel zu optimieren und als Referenz nützlich zu machen, musste ich mehrere Begriffe verwenden, bevor ich sie definierte. Fort- und PMK-Profis sollten mit diesen Begriffen vertraut sein. Anfänger müssen manchmal in den benachbarten Abschnitten nachsehen (ich setze die Links an die richtigen Stellen) oder den Artikel ein paar Mal neu lesen.

161eForth selbst ist hier zusammen mit dem Quelltext, einer grafischen Bildschirmtastatur und help words.txt mit einer Beschreibung aller implementierten Wörter dargestellt: http://the-hacker.ru/2019/161eforth0.5b.zip

Ich habe auch 5 kleine Videos auf YouTube gepostet, die die Funktionsweise des 161eForth für diejenigen veranschaulichen, die den MK-161 nicht haben. Sie können die gesamte Wiedergabeliste auf YouTube ansehen . Unten ist der erste von ihnen, die restlichen 4 am Ende des Artikels.

eForth und seine Umsetzung

eForth wurde als moderner Ersatz für den weithin bekannten fig-Fort-Übersetzer entwickelt. Für die Übertragung auf den MK-161 habe ich eine 32-Bit-Version 5.2 des 86eForth-Übersetzers mit indirekt genähtem Code ausgewählt, die 2016 auf MASM Assembler für das Windows-Betriebssystem geschrieben wurde. Diese Version wird in der dritten Ausgabe von eForth und Zen [1] ausführlich beschrieben. Wenn Sie Englisch sprechen, empfehle ich Ihnen, dieses Buch zu finden und zu studieren. Es ist sehr nützlich, um 161eForth zu verstehen.

In einem persönlichen Brief bestätigte der Autor, dass 86eForth502.asm aus diesem Buch die neueste Version von eForth ist. Im Internet finden Sie viele englischsprachige Informationen zu diesem und früheren Versionen von eForth.

Die Entwicklung von eForth folgte einem wissenschaftlichen Weg, den Professor Wirth am Beispiel seiner Programmiersprache Oberon lehrte. Jede nachfolgende Version von eForth war eine Vereinfachung der vorherigen Version. Alles, worauf verzichtet werden kann, wurde von der Zunge entfernt. Es bleibt eine sorgfältig durchdachte Reihe starker, ausdrucksstarker Sprachkonstrukte übrig, deren Leistungsfähigkeit an mehr als 40 eForth-Implementierungen für verschiedene Plattformen getestet wurde. Jetzt auf dem Rechner!

Als minimalistischer Fort-Dialekt will eForth nicht das Rennen gegen das kleinste Fort gewinnen. Die von ihm angebotenen Wörter sind sehr praktisch und können vom Programmierer leicht in die für seine Aufgaben erforderliche Richtung erweitert werden.

Die erste Version von eForth wurde 1990 in MASM Assembler für 8086-Prozessoren veröffentlicht und arbeitete unter MS-DOS. Es enthielt 31 maschinenabhängige Kernwörter und 191 übergeordnete Wörter. Die Idee war einfach: Sie übersetzen nur 31 Wörter in Ihren Assembler und erhalten eForth sofort auf Ihrem Computer.

Dieser Ansatz wurde im Internet kritisiert, da die Minimierung der Anzahl der Wörter im Assembler zu einer äußerst geringen Leistung für eingebettete Systeme geführt hat. Bereits in der zweiten Version von eForth wurde die maximale Anzahl von Wörtern in Assembler implementiert, was die Neigung nicht nur zu einem leicht tragbaren, sondern auch zu einem praktischen Programmiersystem begradigte.

Bill Munch, der ursprüngliche Autor von eForth, und sein Kollege Dr. Chen-Hanson Ting veröffentlichten mehrere Jahre lang parallel ihre eForth-Veröffentlichungen. Jede Version hatte ihre eigenen Eigenschaften. Die eForth-Optionen für verschiedene Plattformen wurden auch von anderen Programmierern eingeführt.

Die 2016 veröffentlichte Version 5.2 enthält 71 Wörter „Code“ und 110 Wörter „Doppelpunkt“. Ein Vierteljahrhundert der Suche nach dem Ideal hat zu einer signifikanten Reduzierung der Gesamtzahl der Wörter geführt. Gleichzeitig stieg aus Leistungsgründen der Prozentsatz der auf einer niedrigen Ebene implementierten Wörter.

Der vorgeschlagene 161eForth genießt die großzügigen Vorteile dieses Fortschritts, gibt jedoch nicht vor, die Fernleitung weiterzuentwickeln. Meine Implementierung stellt dem Programmierer alle in Version 5.2 vorhandenen Tools zur Verfügung. Wenn die MK-161-Architektur die Implementierung einiger 86eForth-Wörter unmöglich oder bedeutungslos macht, anstatt den Überschuss wegzuwerfen, gebe ich den Programmierern einen vollständigen Ersatz, der dem ANSI / ISO-Standard [4] entnommen ist. Wer Minimalismus sucht, kann selbständig „zusätzliche“ Wörter wegwerfen, da 161eForth traditionell mit Quellcode geliefert wird.

Bei der Implementierung von eForth habe ich mich an das Verständnis des Autors gehalten. Zum Beispiel sollte meiner Meinung nach eine FOR NEXT-Schleife mit einem Anfangswert von n genau n-mal ausgeführt werden. Die gleiche Schlussfolgerung kam schließlich Chuck Moore, der Autor der Sprachen Forth und colorForth. Leider verwendet eForth eine veraltete Konvention und führt einen solchen Zyklus n + 1 Mal mit einem Zähler von n bis 0 aus. Ich habe diesen und einige andere Mängel nicht behoben und die 161eForth-Kompatibilität mit Implementierungen für andere Plattformen bevorzugt.

Da 161eForth mit Ausnahme der Werkssprache das erste praktische On-Board-Programmiersystem für die MK-161-Elektronik ist, habe ich die lange Geschichte von eForth nachverfolgt und einige Wörter in die Sprache zurückgegeben, die auf anderen Plattformen nützlich waren und jetzt möglicherweise gefragt sind.

Beispielsweise enthält die neu-alte Variable 'BOOT' das Token (siehe 3.1) des Wortes, das zuerst ausgeführt wird, nachdem die Umgebung initialisiert wurde, aber bevor der Dialog beginnt. Standardmäßig enthält 'BOOT ein TLOAD-Token zum Interpretieren von Code aus dem „Textbereich“ (siehe 2.4.2). Dies ermöglicht es dem Programmierer, eForth für sich selbst anzupassen, ohne die Umgebung neu zu kompilieren, was an Bord der "Electronics" immer noch nicht möglich ist.

Die vorrangigen Aufgaben der Implementierung waren das Speichern von Binärspeicher (siehe 2.4.1) und die Verbesserung der Leistung. Ihre Lösung führte zu einer dramatischen Verringerung der Anzahl von Wörtern auf hoher Ebene, da ihr Code diesen wertvollen Speicher belegt, da die Anzahl der im billigen Programmspeicher implementierten schnellen Kernwörter zunimmt (siehe 2.4.3).

Infolgedessen enthält 161eForth 129 Codewörter, 78 übergeordnete Wörter und belegt 1816 Byte MK-161-Binärspeicher, dh weniger als die Hälfte davon. Dies gibt Hoffnung auf die Metakompilierung seines hochrangigen Teils direkt an Bord der Elektronik.

Der Quellcode für eForth MK-161 ist in zwei große Teile unterteilt. Der im MK-161-Befehlssystem geschriebene Kern ist in der Datei eForth0.mkl enthalten. Übergeordnete Wörter werden in SP-Forth definiert und in der Datei eForth.f abgelegt.

Die Distribution hat auch eine Hilfedatei words.txt, die alle 161eForth-Wörter mit Stack-Notation und einer kurzen Erklärung in einer Zeile dokumentiert.

1.1 Der Quellcode des Kernels eForth0.mkl

Der eForth-Kern enthält ausführbaren Code, der im Speicher von MK-161-Programmen (siehe 2.4.3) ausgeführt wird und auf einem Computer mit Standardmitteln, z. B. dem proprietären MKL2MKP-Compiler, in die Datei eForth0.mkp kompiliert wird.

Der in der Datei eForth0.mkl enthaltene Kernel-Quellcode ist in lateinischer Mnemonik geschrieben . Beispielsweise wird in dieser Mnemonik ein IPE-Befehl zum Lesen des Registers E (auch bekannt als R14) als RME geschrieben. Lateinische Mnemonik ist für die Besitzer der sowjetischen PMK ungewöhnlich und eignet sich zum Tippen über eine Computertastatur. In der Tat ist es einfacher, seltsame FX ^ 2 zu tippen, als es aus Kindheits-Fx² bekannt ist.

Die Datei eForth0.mkp ist eine Kernel-Voreinstellung. Zusätzlich zum Code der Grundelemente enthält es einen Kernel-Header und eine Tabelle mit Namen tblNames, die eForth.f während der Decodierung in Dezimalregister überträgt (siehe 2.4.4). Auf der Grundlage von eForth0.mkp wird der eForth.mkp-Kern erstellt (siehe 2.4.3), daher muss eForth0.mkl zuerst kompiliert werden.

1.2 Quellcode für übergeordnete Wörter eForth.f

Die Datei eForth.f wird der Eingabe des wunderbaren inländischen Compilers SP-Forth [5] zugeführt. Die Datei enthält Definitionen aller übergeordneten Wörter. Im Laufe der Zeit können sie auf dem eForth selbst identifiziert und möglicherweise direkt an Bord der Electronics MK-161 kompiliert werden.

Während der Kompilierung liest eForth.f das Kernleerzeichen eForth0.mkp und erstellt mit seiner Hilfe drei Dateien im aktuellen Verzeichnis zum anschließenden Laden in MK-161: eForth.mkp, eForth.mkd und eForth.mkb. Es ist eForth.mkb, das die Hauptteile von Wörtern auf hoher Ebene enthält, obwohl sich ihre Überschriften in der Datei eForth.mkd befinden.

Die vierte Datei, eForth.mkt, wird manuell in eForth geschrieben und kann mit dem integrierten Texteditor an Bord des MK-161 bearbeitet werden. Jede dieser vier Dateien werde ich weiter unten genauer analysieren (siehe 2.4).

2. Elektronik MK-161

Ein Hersteller aus Nowosibirsk nennt den MK-161 ein altes Akronym. Das war der Name der allerersten Taschenrechner in der UdSSR. Das Befehlssystem MK-161 erbt das Befehlssystem der sowjetischen Taschenrechner "Electronics B3-34" und "Electronics MK-61". Dies bedeutet, dass Programme, die für sowjetische Taschenrechner geschrieben wurden, ohne Änderungen oder mit geringfügigen Änderungen auf dem MK-161 ausgeführt werden.

Das Gegenteil ist nicht wahr. eForth wird nicht zur sowjetischen PMK gehen, weil verwendet viele Ressourcen, die zuerst im MK-152/161 erschienen sind und in früheren Modellen der Serie nicht verfügbar waren.

Betrachten Sie die Merkmale der Eingabesprache und -architektur des MK-161, die 161eForth (im Folgenden einfach als eForth bezeichnet) beeinflussten und der diskutierten Implementierung von eForth einen „russischen Akzent“ verliehen.

Das erste dieser Merkmale ist die Vereinbarung „Senior at Junior Address“, die in MK-161 konsequent beibehalten wird. Beispielsweise wird die Zahl 1000 = 3 × 256 + 232 in zwei aufeinanderfolgenden Bytes wie 3 und 232 geschrieben.

2.1 Indirekte Adressierung

Programmierung Sowjetische PMK hörte von indirekter Adressierung. Für die direkte Adressierung geben wir explizit die Registernummer an, auf die wir uns beziehen. Zum Beispiel berücksichtigt 44 den Inhalt des Registers 44. Mit der Taste , die in MK-152 erschien, wird auf Register mit der Nummer 15 und mehr zugegriffen - diese Register fehlten im sowjetischen PMK.

Bei der indirekten Adressierung ist die Nummer des erforderlichen Registers nicht im Voraus bekannt. Diese Nummer befindet sich in einem anderen Register. Wenn beispielsweise Register 8 die Nummer 44 enthält, berücksichtigt der Befehl K PI 8 den Inhalt von Register 44 (R44).

Die Tasten K und P können kombiniert werden. Beispielsweise überträgt der Befehl R K BP 20 die Steuerung (GOTO in Latin Mnemonics) an die in R20 gespeicherte Adresse.

Die Funktion, die sich für den internen eForth-Interpreter als wichtig herausstellte, hängt mit der vorläufigen Erhöhung / Verringerung der Register während der indirekten Adressierung zusammen. Diese Funktion wurde von der sowjetischen PMK geerbt.

Beispielsweise reduzieren die indirekten Lesebefehle KI 0, KI 1, KI 2 und KI 3 den Inhalt der Register 0, 1, 2 oder 3 um eins auf das gewünschte Register. Die Befehle KI 4, KI 5 und KI 6 Erhöhen Sie vor dem Lesen den Inhalt der Register 4, 5 oder 6 um eins.

Diese „Änderung“ des Adressregisters ermöglicht es Ihnen, ganze Registergruppen in einer Schleife zu verarbeiten. Es ähnelt ++ R und --R in C. Die Registerregisternummer ist wichtig. Er bestimmt, ob er bei indirekter Adressierung zunimmt (Register 4-6) oder abnimmt (Register 0-3).

Die 161eForth-Architektur wurde durch die Tatsache beeinflusst, dass die Erhöhung der Register 4-6 mit indirekter Adressierung vorläufig ist . Infolgedessen zeigt der Interpretationszeiger (IP) in R6 immer auf das letzte Byte des genähten Codes. In 86eForth gibt IP immer ein nachfolgendes Byte an, das noch nicht gelesen wurde.

Dies gilt auch für den in Register 2 gespeicherten Rückgabestapelzeiger (RP). R2 zeigt immer auf die Oberseite des Rückgabestapels.

Ein nützliches Merkmal des MK-161 ist das Fehlen einer Zunahme / Abnahme des Registers, wenn eine indirekte Adressierung mit dem neuen Schlüssel R auftritt. Beispielsweise zählt RKIP02 die Nummer von der Oberseite des Rückgabestapels, ohne den Zeiger zu ändern. Dies ist ein fertiges Fort R @ -Team. Aus dem Obigen folgt, dass der Lesewert eins weniger ist als die Adresse des nächsten Tokens, das ausgeführt wird, nachdem vom Wort "Doppelpunkt" zurückgekehrt wurde.

Wenn Sie Wörter entwickeln oder studieren müssen, die eng mit dem internen eForth-Interpreter interagieren, müssen Sie diesen subtilen Punkt, der mit Übertreibung verbunden ist, vollständig verstehen.

2.2 Tabellen, geordnet und assoziativ

Die MK-161-Tabellen befinden sich im Programmspeicher (siehe 2.4.3). Sie erschienen in der "Electronics MK" in Nowosibirsk und sind Experten für sowjetische PMK völlig unbekannt. Die Adresse der verwendeten Tabelle wird immer im Register 9042 gespeichert, der Zugriff darauf ist jedoch unterschiedlich.

Eine geordnete Tabelle ist ein Array von vorzeichenlosen 16-Bit-Ganzzahlen. eForth enthält eine solche tblTokens-Tabelle mit den Adressen von Grundelementen (siehe 3.1.1) - Fort-Wörter, die im MK-161-Befehlssystem geschrieben wurden. Der Adressinterpreter (siehe 3.2) verwendet tblTokens, um genähten Code schnell auszuführen. Daher versucht eForth, die Adresse dieser Tabelle in R9042 immer zu enthalten.

Um auf eine bestellte Tabelle zugreifen zu können, müssen Sie die Nummer des gewünschten Artikels in R9210 schreiben. Die Zahl n im Register X wird durch den Wert des Tabellenelements durch die Zahl n ersetzt, die Zählung beginnt bei Null.

Assoziative Tabellen ("Suche nach Wert") werden von eForth aktiv verwendet, hauptsächlich vom Grundelement (FIND), das nach einem Wort mit seinem Namen sucht. Die assoziative Tabelle tblCHPUT wird auch verwendet, wenn Buchstaben auf den Bildschirm gedruckt werden, um Zeilenvorschübe und andere Steuercodes zu verarbeiten.

Um nach dem Element n in der assoziativen Tabelle zu suchen, schreiben Sie n in R9212. Die Nummer n im Register X (das Management nennt sie den "Index") wird durch den 16-Bit-Wert ersetzt, der unmittelbar nach seinem "Index" n in der Tabelle aufgezeichnet ist.

Das Vorhandensein dieser schnellen, wenn auch einfachen Suchfunktion, die in Assemblersprache in der MK-161-Firmware implementiert ist, hat eForth dabei geholfen, eine akzeptable Leistung beim Erkennen von Wortnamen und beim Kompilieren von Programmen zu erzielen. Dazu musste ich natürlich nicht die einfachsten Namenserkennungstabellen entwickeln, die für diese Funktion „geschärft“ wurden. Wir werden im zweiten Artikel ausführlicher darauf eingehen.

2.3 Interrupts und Konsole

Mit „MK Electronics“ können Besitzer Programme in der Eingabesprache schreiben, die auf bestimmte Ereignisse reagieren - z. B. Drücken oder Loslassen einer Taste, Beenden einer Timer-Zählung.

eForth verwendet dieses Interrupt-System aktiv sowohl für die Tastatureingabe als auch für einen blinkenden Cursor, wenn Sie zur Eingabe aufgefordert werden, sowie für die Eingabe / Ausgabe über eine universelle serielle Schnittstelle (RS-232).

Die über die Tastatur eingegebenen Buchstaben werden beim Drücken der Tasten bufKbd in die Warteschlange gestellt. Dies ist sehr praktisch und spart Zeit bei Systemen mit niedriger Geschwindigkeit. Das Umschalten von Alphabet und Groß- / Kleinschreibung wird vom KeyPress-Interrupt übernommen und belegt keinen Platz in der Warteschlange. Durch langes Drücken der Taste wird die automatische Wiederholung aufgerufen.

Wenn die Zeile mit 8 Buchstaben voll ist und eForth noch nicht bereit ist, die Eingabe zu verarbeiten (die Situation ist sehr selten), gibt der MK-161 ein unglückliches Quietschen aus. Natürlich möchte ich nicht all diese natürliche Arbeit der Tastatur im Übersetzer implementieren, sondern den MK-161 als Service der Firmware (Firmware) "out of the box" bekommen. Aber was, wie sie sagen, ist reich.

Nach Arbeitsbeginn wird die gesamte eForth-Ausgabe auf den Grafikbildschirm MK-161 geleitet. Die Ausgabe von Buchstaben darauf erfolgt durch eine relativ einfache Routine des CNCut. Die einzige Schwierigkeit hierbei ist die Implementierung des BS-Steuercodes, des "Space Back". MK-161 verwendet eine proportionale Schriftart. Daher müssen Sie sich in einem speziellen Puffer tblBS die Positionen der angezeigten Zeichen merken, von denen der BS-Ausgabecode sie später übernimmt.

Während des Dialogs kann der Benutzer das Wort IO> verwenden, um alle E / A an die serielle RS-232-Schnittstelle umzuleiten, wodurch der MK-161 von einer bekannten Computertastatur oder von einem anderen MK-161 aus programmiert werden kann . Das Wort CON> gibt die Steuerung an die Rechner-Konsole zurück.

2.4 Speicherbereiche und Installation von eForth auf dem MK-161

Der Speicher „MK-161 Electronics“ besteht aus einem separat adressierbaren Programmspeicher und einem Datenregisterspeicher. Der Registerspeicher ist wiederum heterogen und in drei große Bereiche unterteilt.

Register mit Zahlen von 0 bis 999 speichern "Dezimalzahlen". Dies sind gewöhnliche Register wie in "Electronics B3-34" und anderen Taschenrechnern. Sie können einfach nicht 8, sondern 12 Dezimalstellen der „Mantisse“ speichern.

Register mit Nummern von 1000 bis 8167 speichern Ganzzahlen von 0 bis 255. Die letzten 3 KB dieses Bereichs mit Adressen von 5096 bis 8167 werden als Textbereich bezeichnet .

Register mit Nummern von 9000 bis 9999 werden Funktionsregister genannt. Dieser Servicebereich des Adressraums ähnelt Mikroprozessor-E / A-Ports. Mit Hilfe von Schreib- und Lesebefehlen werden diese Adressen für den Zugriff auf E / A-Geräte, Interrupt-Systeme usw. verwendet.

Um eForth auf "Electronics MK-161" zu installieren, reicht es aus, vier Dateien auf den Taschenrechner zu übertragen, beispielsweise mit dem Programm des Herstellers MK.EXE:

• Schreiben Sie eForth.mkp ab Seite 0 in den Programmspeicher. Version 0.5b belegt 74 Seiten.
• Schreiben Sie eForth.mkd in den dezimalen Datenspeicher
• Schreiben Sie eForth.mkb in den Binärdatenspeicher
• Schreiben Sie eForth.mkt in den Textspeicher

Nach der Übertragung auf den Taschenrechner empfehle ich , diese vier Dateien sofort in einem separaten Verzeichnis der eingebauten „elektronischen Festplatte“ zu speichern. Da sie denselben Namen haben, können Sie eForth sofort als „Paket“ herunterladen.

2.4.1 Binärspeicher ("Byte") MK-161: eForth.mkb

Die MK Electronics-Register mit Zahlen von 1000 bis 5095 werden zum Speichern von Zahlen von 0 bis 255 verwendet. Dieser Bereich des Registerspeichers des Rechners wird als binär bezeichnet. Auf zwei aufeinanderfolgende Binärregister kann von eForth als einzelne 16-Bit- "Zelle" zugegriffen werden, und (wie überall beim MK-161) befinden sich die oberen 8 Bits im Register mit einer niedrigeren Nummer.

eForth verwendet diesen winzigen „Binärspeicher“ als primären Speicher. Worte funktionieren mit ihr! und @, HERE und ALLOT, nur von hier aus führt der Adressinterpreter den genähten Code aus (siehe 3.2). Hier sind die eForth-Variablen, der Texteingabepuffer (TIB), das Wörterbuch und der tblBS-Rollback-Stack zum Implementieren der Rücktaste.

4096 Bytes sind für moderne Verhältnisse sehr bescheiden. Daher wurden enorme Anstrengungen unternommen, um alles Mögliche in andere Bereiche des Gedächtnisses zu bringen.

2.4.2 Textbereich: eForth.mkt

Unmittelbar nachdem der Binärspeicher ein Textbereich ist , werden Register mit Zahlen von 5095 bis 8167 registriert. Technisch gesehen handelt es sich um dieselben Byteregister, aber die Möglichkeit, sie auf die Festplatte zu schreiben und als separate Datei zu lesen, macht diesen Bereich zu etwas Besonderem.

Das Wort TLOAD wird verwendet, um in eForth mit „Text“ zu arbeiten. Dieser gesamte Bereich wird der Eingabe des Textinterpreters als Zeichenfolge mit einer Länge von 3072 Buchstaben zugeführt.

Es gibt Meinungsverschiedenheiten darüber, wie Text in Zeilen unterteilt werden soll. Ein in MK Electronics integrierter Editor besteht auf einer Zeilenlänge von 24 Zeichen. Callisto verwendet die Fort-Konvention, bei der die Zeichenfolge 64 Zeichen enthält. eForth bietet dem Benutzer eine Auswahl, bei der der gesamte Text als eine lange Zeile gezählt wird. Sie können den eingebauten Editor MK-161 verwenden. Sie können Ihre eigenen schreiben, kompatibel mit Callisto.

Hier ist der anfängliche Inhalt von eForth.mkt der Einfachheit halber in drei Zeilen unterteilt:

: hi ." , %user%!" CR ; ' hi 'boot ! hi \ 

Die erste Zeile definiert das neue Wort hi, das den Benutzer begrüßt. Die zweite Zeile nimmt das Token dieses Wortes (siehe 3.1) und platziert es in der Variablen 'BOOT (siehe 1). Jetzt wird der Textbereich bei jedem Start von eForth nicht mehr kompiliert. Stattdessen wird die bereits kompilierte Begrüßung ausgeführt.

Die letzte Zeile beginnt mit dem Wort hi und zeigt eine Begrüßung auf dem Bildschirm an. Das Wort \ vervollständigt die Interpretation des Textes und gibt die Steuerung an die Konsole zurück.

Um eine beliebige Textdatei zu kompilieren, müssen Sie mit dem Befehl BYE zum Taschenrechner gehen, zum Hauptmenü gehen und die gewünschte Datei im DOS-Modus laden. Sie können die mkt-Datei auch von einem Computer übertragen. Mit der C / P-Taste kehren Sie zu eForth zurück. Anschließend können Sie mit dem Befehl TLOAD die in den Textbereich geladene Datei kompilieren.

2.4.3 Programmspeicher: eForth.mkp

Der Programmspeicher MK-161 ist ein isolierter Adressraum. Es werden auch Bytes gespeichert, die jedoch schreibgeschützt sind. Der Programmspeicher enthält 10.000 "Schritte", die sich für eForth als redundant herausstellten. Mehr als ein Viertel des Programmspeichers erwies sich als frei, was eine gute Reserve für die Entwicklung des Übersetzers darstellt.

Nur im Programmspeicher können "Codewörter" implementiert werden. Außerdem werden hier Namenserkennungstabellen und alle bekannten Textzeichenfolgen gerendert, wodurch Binärspeicher gespart wird.

Einige Wörter wie C @, COUNT und TYPE können den Programmspeicher adressieren, wenn die Adresse keine positive Zahl ist. Beispielsweise zählt die Phrase 0 C @ als "Schritt" (Byte) von der Adresse 0 des Programmspeichers.

2.4.4 Dezimalspeicher: eForth.mkd

Die Register von MK Electronics mit Zahlen von 0 bis 999 werden als Dezimalzahlen bezeichnet und enthalten Zahlen, die für normale Berechnungen auf dem Taschenrechner verwendet werden - 12 Dezimalstellen der „Mantisse“ und 2 Dezimalstellen der „Ordnung“. Das Fort ist für die Arbeit mit Ganzzahlen mit einer Länge von bis zu 4 Byte ausgelegt. Eine solche Ressource ist für eForth eindeutig redundant.

Der Dezimalspeicher wird verwendet, um wertvollen Binärspeicher zu speichern. Hier werden Datenstapel und Retouren erstellt. Hier werden die Überschriften der Wörter gespeichert - sowohl benutzerdefiniert als auch eingebettet, ein Register pro Titel. Mit diesem Ansatz können Sie auch Wörter mit Standardnamen neu definieren.

Der Stapel im Dezimalspeicher führt zu einer Reihe von Merkmalen, die für das Fort des MK-161 charakteristisch sind. Erstens ist der Wertebereich der Stapelelemente sehr groß und kann 32-Bit-Ganzzahlen aufnehmen. Die Notwendigkeit für "doppelte Ganzzahlen" beim MK-161 verschwindet, obwohl ich aus Kompatibilitätsgründen die entsprechenden Wörter eForth implementiert habe. "Doppelte Ganzzahlen" werden auf MK-161 als zwei Stapelelemente dargestellt, die Zahlen von 0 bis 65535 enthalten und eine 32-Bit-Ganzzahl mit einem Vorzeichen im zusätzlichen Code codieren. Die hohen 16 Bits dieser Nummer werden oben platziert, dh an der niedrigsten Adresse.

Die bitweisen logischen Operationen AND, OR, XOR und NOT behandeln ihre Argumente als 16-Bit-Ganzzahlen. Ein Ergebnis von 32768 bis 65535 wird in negative Zahlen von -32768 bis -1 umgewandelt. In eForth wird false mit Null und Wahrheit minus Eins codiert. Ebenfalls wahr ist ein anderer Wert als Null.

Das zweite Merkmal des 161eForth-Datenstapels besteht darin, dass er vorzeichenbehaftete Nummern enthält. Wenn das Wort @ die Nummer 65535 aus einer 16-Bit-Zelle liest, wird es automatisch in -1 konvertiert. Ein spezielles "vorzeichenloses" Wort U @ wird bereitgestellt, um direkt 65535 mit einem Pluszeichen zu zählen.

Ich erinnere mich, dass sich die beiden oberen Elemente des Datenstapels der Geschwindigkeit halber nicht im Dezimalspeicher befinden, sondern direkt in den X- und Y-Registern .

Die Tatsache, dass Dezimalregister Bruchzahlen und Gleitkommazahlen enthalten können, wird von eForth nicht verwendet. Die virtuelle eForth-Maschine verwendet diese Register, um vorzeichenbehaftete 12-Bit-Dezimalzahlen zu speichern. Auf Dezimalregister wird mit den Wörtern C @ und C zugegriffen! - die gleichen, die mit einzelnen Registern arbeiten.

3. Der interne Interpreter

Der eForth-Kern ist ein Programm, das in der Eingabesprache MK-161 geschrieben ist. Ihr erster MAIN-Befehl überträgt die Kontrolle auf den MAIN-Code, der zunächst die Umstände des Neustarts ermittelt. Wenn es durch den falschen Token verursacht wurde, quietscht MK-161. Beim ersten Start und auch nach dem Einschalten des MK-161 wird der Bildschirm gelöscht. Als nächstes ruft MAIN die Init-Subroutine auf, um das Interrupt-System und alles, was die MK-161-Konsolentreiber benötigen, zu initialisieren.

Nach dem Initialisieren der Datenstapel und der Rückgabe ist der Teil des Starts auf niedriger Ebene abgeschlossen. Unglaubliche Dinge passieren für Maschinen mit Harvard-Architektur - eForth führt weiterhin „verkabelten Code“ aus dem Bytespeicher aus. Die Ehre, der Erste zu sein, gehört zu einem Wort, dessen Kopfadresse in R43 aufgezeichnet ist. Dies ist normalerweise das Wort KALT.

Wie sind hochrangige Wörter (IEDs) angeordnet? Jedes Wort besteht aus zwei Teilen, einem Körper und einer Überschrift. Der Header wird dezimal gespeichert. Es hilft dem externen Interpreter und Dekompiler, den Namen und den Textkörper des Wortes zu finden. Die Überschrift enthält auch ein „Lexikon“ -Feld - eine Reihe von Flags, die dem externen Interpreter helfen, das gefundene Wort korrekt zu verarbeiten. Der interne Interpreter ist für den VCA-Body, der sich im Binärspeicher befindet und im Wörterbuch gespeichert ist, viel wichtiger. Er kann sogar Wörter ausführen, die keine Überschrift haben.

Der Hauptteil des VCA beginnt mit dem Byte des Codefelds , das die Adresse des Prozessors des angegebenen Wortes enthält. Vier VCA-Handler sind in der Eingabesprache MK-161 geschrieben und beginnen auf der ersten Seite des Programmspeichers. Wir werden sie alle analysieren (siehe 3.3), aber die wichtigste heißt DOLST und befindet sich an der Adresse 02, unmittelbar nach dem bereits berücksichtigten Befehl MAIN BP. Dieser Handler führt Fort-Wörter aus, die mit einem Doppelpunkt definiert sind.

Nach dem Byte des Codefeldes befindet sich ein Parameterfeld beliebiger Länge. In den "Doppelpunktwörtern" enthält das Parameterfeld einen "genähten Code" - eine Folge von 16-Bit-Token, von denen jeder eine ihm zugewiesene Aktion angibt.

Zunächst werden wir das Token genauer betrachten. Dann werden wir den internen INEXT-Interpreter untersuchen, der von einem Token zur Ausführung des nächsten überträgt. EForth nennt INEXT einen primitiven Handler. Wir schließen diese Tour durch den internen Interpreter mit der Analyse aller vier IED-Prozessoren ab.

3.1 Token

Das Token repräsentiert das Wort im genähten Code und Stapel, sodass es schnell ausgeführt werden kann. Das Token ist ein Zeiger auf den Wortkörper, aber die raue Architektur des MK-161 hat diese einfache Idee selbst angepasst. Lassen Sie uns alle Arten von Token analysieren, beginnend mit dem primitiven Token.

3.1.1 Primitives Token

Alle in der eForth-Verteilung enthaltenen Wörter sind von 0 bis 206 nummeriert. Diese Nummerierung erfolgt durchgehend, wobei sowohl Grundelemente als auch VCA berücksichtigt werden. Dies geschieht so, dass es durch die Nummer des Wortes leicht war, seinen Namen wiederherzustellen. Diese Namen werden im Programmspeicher gespeichert. Der Link zum gewünschten Namen ist leicht über die Headertabelle zu finden.

Die primitive Zahl ist ihr Token . Wie jedes Token benötigt das Grundelement zwei Bytes im genähten Code. Der erste ist Null. Der zweite enthält seine Nummer. In der Tabelle tblTokens können Sie die Adresse des primitiven Codes anhand dieser Nummer schnell finden. Die tblTokens-Adresse ist permanent in R9042 gespeichert (siehe 2.2), dh es ist immer alles zur Hand, um das Grundelement auszuführen.

Mit dem Wort XT> können Sie die Adresse eines primitiven Codes anhand seiner Nummer (Token) ermitteln. Da sich der Code der Grundelemente immer im Programmspeicher befindet, ist die empfangene Adresse immer negativ (siehe 2.4.3).

3.1.2 VCA-Token

VCA kann eine eigene Nummer und einen zugehörigen Standardnamen haben oder vom Benutzer erstellt werden. In allen Fällen ist das VCA-Token die Adresse seines Codefelds (siehe 3), dh eine Zahl von 1000 bis 5095.

Im genähten Code wird das VCA-Token auf sehr ungewöhnliche Weise geschrieben. Die Anzahl von Hunderten (eine Zahl von 10 bis 50) wird in das erste Byte geschrieben, der Rest aus der Division des Tokens durch 100 (eine Zahl von 0 bis 99) im zweiten Byte.

Beispielsweise wird das Token 1234 durch zwei Bytes 12 und 34 dargestellt. Die Kompilierung dieses und jedes anderen Tokens erfolgt unter Verwendung des aus dem ANSI-Standard entnommenen Wortes COMPILE. Um VCA-Token im genähten Code zu schreiben und zu lesen, müssen die Wörter XT! und XT @. Sie greifen auf Adressen zu (siehe 3.1.4), und das Wort XT @ kann auch das primitive Token lesen.

3.1.3 Ganzzahlige Literale

Ganze Literale sind eine Art primitiver Token. Sie sind ungewöhnlich genug, um separat betrachtet zu werden.

Im genähten Code belegen die Token DOLIT und DOLITM vier Bytes. Die ersten beiden Bytes enthalten das bereits berücksichtigte primitive Token, dh 0, und die Nummer des Grundelements. Die nächsten zwei Bytes enthalten eine Ganzzahl, die das angegebene Literal während der Ausführung auf den Datenstapel legt.

DOLITM unterscheidet sich darin, dass es das Vorzeichen der Zahl ändert, bevor es auf den Stapel gelegt wird. Es wurde entwickelt, um negative Zahlen zu implementieren.

3.1.4 Adressliterale

Wie ganze Literale belegen die drei Adressliterale BRANCH, BRANCH und DONXT jeweils 4 Bytes im genähten Code. Die ersten 2 Bytes enthalten das primitive Token, die letzten beiden Bytes sind die Sprungadresse.

Die Adresse wird im gleichen Format wie das VCA-Token aufgezeichnet (siehe 3.1.2). Das erste Byte enthält die Anzahl von Hunderten, das zweite den Rest der Division der Adresse durch 100. Ich erinnere mich, dass die Übergangsadresse aufgrund von Übertreibung (siehe 2.1) nicht die Adresse des gewünschten Tokens enthält, sondern eine Zahl, die um eins kleiner ist.

Das DONXT-Token hilft bei der Implementierung des FOR-NEXT-Endzyklus (siehe 1). Der bedingungslose BRANCH-Sprung wird benötigt, um die Endlosschleife BEGIN-AGAIN zu implementieren. Bedingte Verzweigung? BRANCH überträgt die Kontrolle, wenn sich Null oben im Datenstapel befindet (false). Es dient zur Implementierung der bedingten IF-THEN-Anweisung, die aus "unbestimmten Schleifen" BEGIN-UNTIL und BEGIN-WHILE-REPEAT beendet wird.

3.1.5 String-Literale

String-Literale sind eine Art VCA-Token. Im genähten Code eines String-Literal gibt es nach dem Token ein Byte mit der Länge des Strings, nach dem der String selbst vom ersten bis zum letzten Byte ist.

EForth hat drei String-Literale: $ "|,." | und abort "|. Sie werden in der Datei eForth0.mkl als STRQP-, DOTQP- und ABORQ-Token definiert. Die Hauptarbeit" literal "wird durch das Wort do $, das DOSTR-Token, ausgeführt.

Um die Artikelgröße angemessen zu gestalten, kann ich mich nicht zu sehr mit diesem interessanten Thema befassen, aber es ist schön zu wissen, ob sie in eForth verfügbar sind.

3.2 Adressinterpreter

Es ist Zeit, den Token-Interpreter zu betrachten , dessen Adresse immer in Register 9 geschrieben ist. Die meisten Grundelemente beenden ihre Arbeit mit dem Befehl K BP 9, der die Kontrolle an das INEXT-Label überträgt.

 INEXT: 6 Fx≠0 NPrime NData:  2 6 + 7 F⟳ 7 8 F⟳ 8 

Zunächst liest der Adressinterpreter das erste Byte des nächsten Tokens mit dem Befehl KIP6. Wenn es Null ist, ist dies ein Grundelement und der Code unter der Bezeichnung NPrime behandelt das Token.

Das Label NData kennzeichnet die Verarbeitung des VCA-Tokens. Das erste Byte wird mit dem Befehl VP 2 mit einhundert multipliziert. Danach addiert KIP6 + das zweite Byte des Tokens zum Ergebnis (siehe 3.1.2). Das Lesetoken wird vom P7-Team in das Arbeitsregister WP (R7) eingetragen.

Wir wissen, dass das VCA-Token die Adresse seines Codefelds ist, das die Adresse des Prozessors enthält. Die KIP7 P8-Befehle lesen das Byte des Codefelds in R8, und der KBP8-Befehl überträgt die Steuerung an den VCA-Prozessor. Der Handler weiß, dass R7 eine Nummer eins enthält, die kleiner ist als die Adresse des Parameterfelds des verarbeiteten Wortes.

Befehle F⟳ mit Code 25 werden auf dem Stapel „aufgeräumt“. Tatsache ist, dass eForth die beiden obersten Elemente des Datenstapels direkt in den X- und Y-Registern des MK-161-Stapels speichert. Eine solche Lösung beschleunigt die Arbeit, muss jedoch sicherstellen, dass diese wichtigen Daten nicht verloren gehen.

Es bleibt zu verstehen, wie der Adressinterpreter die Grundelemente ausführt.

 NPrime: F⟳ 6 9210 8 F⟳ 8 

Der KIP6-Befehl liest das zweite Byte des primitiven Tokens. RRP9210 P8-Befehle lesen die Adresse dieses Grundelements aus der Tabelle tblTokens (siehe 2.2 und 3.1.1), und KBP8 überträgt die Steuerung an dieses Grundelement.

Wie oben entfernt F⟳ den Überschuss vom Stapel und stellt den Inhalt der Register X und Y wieder her.

Der eForth-Adressinterpreter ist so klein, dass er mehrmals im Programmspeicher dupliziert wird. Die Hauptkopie wird mit dem Befehl K BP 9 ausgeführt, der die meisten Grundelemente vervollständigt.

Als Übung empfehle ich, die Implementierung des Wortes EXECUTE zu studieren, das nach dem EXECU-Label steht. Dies ist eine INEXT-Variante, die das Token nicht aus dem genähten Code liest, sondern aus dem Datenstapel entnimmt.

3.3 VCA-Handler

Vier VCA-Sorten haben vier verschiedene Handler: DOLST, DOVAR, DOCON und DOCONM. Wir haben oben bereits gesehen, dass der Adressinterpreter vor dem Aufrufen des Handlers in R7 die Adresse des Codefeldes des zu verarbeitenden Wortes hinterlässt.

eForth.f lernt die Adressen dieser Handler, indem es den Kernel-Header aus der Datei eForth0.mkp liest. Dies hilft ihm, den VCA für den Electronics MK-161 korrekt zu kompilieren, indem das Ergebnis in die Datei eForth.mkb eingefügt wird.

3.3.1 Doppelpunktwörter: DOLST und EXIT

Das nächste wichtige Thema nach INEXT ist, was der interne Interpreter tut, wenn er auf das Token eines durch Doppelpunkte definierten Wortes stößt. Das Codefeld eines solchen Wortes enthält die Nummer 2, daher überträgt INEXT die Steuerung an den DOLST-Handler, der die erforderlichen Arbeiten ausführt, um mit der Interpretation der neuen Liste von Token zu beginnen.

 DOLST: 6 2 F⟳ 7 6 F⟳ INEXT: 

Register 2 enthält, wie bereits erläutert (siehe 2.1), einen RP-Rückgabestapelzeiger. Die IP6 KP2-Befehle schreiben den Wert von R6, dem Interpretation Pointer (IP), in den Rückgabestapel. Später hilft dies dabei, sich an die aktuelle Position in der alten Liste der Token zu erinnern, an der INEXT auf ein Doppelpunktwort gestoßen ist. Jetzt ordnet IP7 P6 IP an den Anfang einer neuen Liste.

Unmittelbar nach dem DOLST-Code wird der INEXT-Code platziert, der das erste Wort der neuen Token-Liste ausführt. Wie an anderer Stelle helfen die Befehle F dabei, die beiden obersten Elemente des Datenstapels beizubehalten.

Doppelpunktwörter enden normalerweise mit einem EXITT-Token, was im Vergleich zu DOLST das Gegenteil bewirkt - es nimmt den alten IP-Wert vom Rückgabestapel und kehrt zur Interpretation der alten Token-Liste zurück.

 EXITT: 02 6 x 1 2 + 2 F⟳ INEXT: 

Die Befehle RKIP02 P6 lesen den alten IP-Wert vom oberen Rand des Rückgabestapels (siehe 2.1). Danach korrigieren die Befehle Cx 1 IP2 + P2 den Wert von RP und erhöhen ihn um eins. Der Befehl F⟳ stellt den Stapel wieder her, wonach INEXT das nächste Wort aus der alten Token-Liste ausführt.

Natürlich kann INEXT nicht gleichzeitig nach DOLST und nach EXITT gehen. Dazu habe ich einen alten Trick aus der Zeit der UdSSR angewendet. Sie können es auch beherrschen, indem Sie die entsprechenden Zeilen in der Datei eForth0.mkl untersuchen.

3.3.2 DOVAR-, Variablen- und Array-Handler

Wörter, die durch die Wörter CREATE und VARIABLE generiert werden, verwenden denselben DOVAR-Handler. Dieser Handler überträgt auf dem Stapel die Adresse der Variablen, die sich im Parameterfeld befindet und unmittelbar nach dem Byte des Codefelds steht. VARIABLE-Variablen belegen 2 Bytes, und die mit CREATE erstellten Arrays enthalten so viele Bytes, wie der Programmierer möchte.

 DOVAR: ⇔ 3 x 1 7 + 9 

Befehle ⇔ KP3 speichern den Inhalt des Registers Y im Datenstapel. Gleichzeitig wird die Nummer von der Oberseite des Stapels in RY eingegeben, wodurch RX auf den neuen Wert freigegeben wird. Nach Cx 1 IP7 + -Befehlen wird dieser neue Wert oben im Stapel zur Adresse des Parameterfelds des ausführbaren Wortes. KBP9 überträgt die Kontrolle ohne Tricks an INEXT und fährt mit dem nächsten Wort fort.

3.3.3 Konstante Handler: DOCON und DOCONM

Im Gegensatz zu DOVAR greift der Konstantenhandler auf das Parameterfeld seines Wortes selbst zu. DOCON liest einen 16-Bit-Konstantenwert daraus. Dieser Wert ist immer positiv.

 DOCON: ⇔ 3 ⇔ 7 5 x 256 5 × 5 + 9 

Befehle ⇔ KP3 ⇔ speichern RY im Datenstapel. Diesmal kehrt die alte Spitze des Datenstapels zu RX zurück. Die IP7 P5-Befehle erzwingen es zurück in RY, während das Zeigerregister R5 vorbereitet wird, um den Wert der Konstante zu lesen. Als nächstes ersetzt Cx 256 den Müll in Register X durch die Nummer 256.

Instrumente KIP5 × KIP5 + lesen eine Konstante aus dem Parameterfeld an die Spitze des Datenstapels, dh in RX. Wie wir uns erinnern, ist in MK-161 das erste Byte immer hoch. Es wird mit 256 multipliziert, wonach das niedrigstwertige Byte der Konstante zum Produkt hinzugefügt wird. Alle Arbeiten sind erledigt, KBP9 überträgt die Kontrolle auf das nächste Wort.

DOCONM funktioniert genauso, nur das konstante Vorzeichen nach dem Lesen ändert sich in das Gegenteil. Aus Gründen der Geschwindigkeit sind auf dem MK-161 negative Konstanten als separater Prozessor implementiert:

 DOCONM: ⇔ 3 ⇔ 7 5 x 256 5 × 5 + /-/ 9 

Jetzt haben wir vollständig herausgefunden, wie eForth seinen Code auf dem MK-161 Electronics aus dem Datenbereich ausführt, und sogar ein tieferes Thema der String-Literale angesprochen (siehe 3.1.5).

Im zweiten Artikel der Reihe werde ich über den externen "Text" -Interpreter 161eForth sprechen, die Struktur der Headertabellen analysieren und die Namen erkennen. Für diesen Teil des Übersetzers musste ich viel radikalere Lösungen entwickeln, vor deren Hintergrund das oben diskutierte traditionelle Fort alt und gut ist.

Happy Fort Programmierung!

Literatur

1. Dr. Chen-Hanson Ting. eForth und Zen - 3. Ausgabe, 2017. Verfügbar auf Amazon Kindle.
2. Baranov S.N., Nozdrunov N.R. Fort Sprache und ihre Umsetzung. - L.: Maschinenbau. Leningrad Abteilung, 1988.
3. Semenov Yu.A. Programmierung in der FORT-Sprache. - M.: Radio und Kommunikation, 1991.
4. ANS Vierter Standard. X3.215-1994. Übersetzung
5. SP-Forth-Dokumentation .
6. Offete Store (Proceedings of Dr. Chen-Hanson Ting) , in dem Sie 86eForth v5.2 für Windows herunterladen können, Dokumentation in englischer Sprache.

Videoabbildungen

Diese vier kleinen 161eForth-Videos werden fortgesetzt. Das erste Video am Anfang des Artikels.

Teil 2 von 5. Testet TEST-TEST4 aus dem Buch "eForth and Zen", 3. Auflage, auf dem MK-161.



Teil 3 von 5. SIEHE Dekompiler.



Teil 4 von 5. Haltepunkt BYE, RS-232-Terminal und Fernzugriff auf MK-161.



Teil 5 von 5. Schlussworte.