Vision: auf der klassischen Original-Hardwarebasis eines C64 von Grund auf neu geschaffene moderne System-Software in 16 KB ROM?

Toll, danke, Stephan!

Dann fange ich einmal mit einem Fazit aus der bisherigen Diskussion aus meiner Sicht an:

An die Debatte thematisch angrenzend:

• Optimierungsgrad (-potential) des existierenden Kernals/Basic-Interpeters als wichtige (historische) Informations- und Erfahrungsquelle
  
• Debatten zur Compilertechnik und zum Programmiersprachendesign im Hinblick auf das existierende 6510-System
• User-Präferenzen zur Nutzung des heutigen aber auch eines zu "erfindenden" Systems

Zur Vision selbst:

• Es gelten nur Lösungen, die es tatsächlich den Usern erlauben, von Anfang an mit der Maschine allein und historisch etablierten Peripheriegeräten, ohne weitere äussere Hilfsmittel (wie PC-Cross-Compiler etc.), einigermassen simpel (also vergleichbar dem on board Basic-Interpreter und -Editor) loszulegen.
• Es ist aber ausdrücklich erlaubt und erwünscht, dass so eine Lösung mit externen Hilfsmitteln / Erweiterungen etc. gut zusammenarbeitet, wenn man das wünscht.

Was bisher geschah:

Die Vermutung steht im Raum, dass eine Virtuelle Maschine viel Platz sparen könnte.

Eine Diskussion ist am Laufen, ob diese Maschine ev. so gestaltet werden könnte, dass Funktionalität schnell und einfach "compiliert" werden kann (also so, dass der Compiliervorgang sich auf kleine Einheiten bezieht, und in der Größenordnung ungefähr so verhält wie das Übernehmen einer BASIC-Zeile). Das ist mit ein paar konzeptuellen Schwierigkeiten verbunden: Z.B. was macht man mit den Identifiern? Wie behält man Formatierungsinformation bei (z.B. Zeilenvorschub, Tab, Einrückungstiefe, etc.). Wie bewahrt man Kommentare? Dazu gibt es zwar Vorschläge, aber ob die machbar sind, ist nicht heraussen.

Eine weitere Frage ist, ob so ein Byte-Code allgemein und effizient genug sein könnte, damit es sich auszahlt, weitere Compiler zu schreiben, die ihn als Zielsprache verwenden. Wenn man das macht, stellt sich weiter die Frage, ob man solche Compiler bereits auf dem C64 laufen lassen könnte, und unter welchen Bedingungen.

Sehr wichtig ist die Frage, ob diese VM schnell genug sein könnte, um Teile der Kernal-Funktionalität darin auszudrücken, und wenn ja, wo die Grenze sein müsste.

Falls ich nichts vergessen oder falsch verstanden habe, wäre das soweit der Stand der Gedanken.

Hm...also ich hääte gerne eher mehrere und dafür spetiallisierte kernels -die ich dann auf ner 30Fach Umschaltplatine einsetze und immer den Kernel für den enrsprechenden Usecase verwende. Was ich mir da vorstellen könnte:

• Ein SW-Entwicklungs Kernele (eine für BASIG, einen für ASM)
• Einen Kernel Entwicklungskernel
• Einen Internett Browser Kernel
• Einen BBS-Kernel
• Einen SimonBasicExtended Kernel
• Einen Kernen mit C64-Scratch (ja das wäre der Traum fürs Coder Dojo)
• Einen Sound Entwicklungskernel
• Einen DOS-Kernel
• Einen IO-Kernle (spetialisiert auf CIA-IO anwendungen wie Robotersteuerungen).

Könnte man diese Anforderungen theoretisch in einen gemeinsamen und einen jeweils spezialisierten Teil aufspalten? Denn dann könnte man diese Teile eben nicht mehr als "Kernel", sondern als entsprechende Treiber oder Libraries konzipieren, die man bei Bedarf nachlädt oder einblendet.

Bzw. - was ich nicht weiß - ist SimonsBasicExtended z.B. mit einem neuen Kernal ausgestattet? Ich kanns mir vorstellen, aber eigentlich sollte man ja annehmen, dass in erster Linie der BASIC-Teil verändert ist?

Wobei, wie mir grade auffällt, man die mit dem angepeilten Konzept ja alle nachbauen müsste, denn die ursprünglichen Implementierungen würden kaum mehr ins (neue) Konzept passen.

Ich schreibe einmal eine Grund-Idee her, ob sie brauchbar ist, mögen andere entscheiden:

Ich würde als VM-Sprache eine pseudo-funktionale Sprache vorschlagen, wobei sich fast alles auf dem Daten-Stack abspielt. Dabei liegen Daten- und Return-Stack irgenwo im RAM (nicht der System-Stack!), was durch zwei Stack-Register (in der ZP) dargestellt wird.

Jede Operation bezieht sich im einfachsten Fall direkt auf die obersten Stack-Elemente, kann aber auch auf andere Stack-Elemente addressiert werden. Es wirft die erste Frage sich auf: Wieviele Bits gönnen wir dieser Addressierungsform? Ich würde vorschlagen, das mit der Größe des Stack-Fensters zu kombinieren, das günstigerweise auch in der ZP liegt.

Mir erscheinen intuitiv 16 oder 32 Bytes für dieses Fenster als vernünftig, und ich würde mir den Mechanismus so vorstellen: Der Stack wird in einem geschlossenen Kreislauf befüllt, und wenn neue Elemente gebraucht werden, werden 8 Bytes in einem auf den Stack "draussen" geschrieben, und im ZP-Fenster somit zum Überschreiben freigegeben. Sollte der Stack wieder geleert werden, werden sie wieder von draussen zurück geholt, und das immer in je 8(vielleicht auch 16?) Bytes-Portionen.

Eine schnelle Stack-Adressierungsart wäre dann vermutlich mit 8 byte Reichweite sinnvoll. Eventuell mit 16. Darüber gehört noch nachgedacht. Jedenfalls könnte man so lokal fast immer für ZP-Zugriffe garantieren.

Man braucht natürlich weitere Addressierungsmodi: Für lange Stack-Zugriffe, für absolute Speicher-Zugriffe inklusive jeder Indizierungsvarianten, und für virtuelle Speicher-Zugriffe inklusive Indizierungsvarianten. Letztere dienen dazu, Paging zu ermöglichen, und jedem Programm quasi seinen eigenen Adressraum zu geben.

Diese Addressierungsmodi bräuchten aber nicht alle Befehle betreffen. Es würde ausreichen, wenn man damit bloß Werte in das lokale Stack-Fenster holen kann und von dort wieder hinausschreiben. Eventuell ist es aber zwecks Optimierung sinnvoll, die Befehle trotzdem zu erlauben, die der 6510 schon selbst mit interessanten Addressierungsmodi anbietet, um die nicht unnötig zu verlangsamen.

Im Stackfenster spielen sich fast alle einfachen Operationen ab, also Addition, Multiplikation, bitweise Verknüpfungen, etc. Dabei stellt sich sofort die Frage, ob man dafür noch extra Register mit absoluter Addresse benutzen sollte, umkopieren, und dann die Operation durchführen, oder ob das ZP indiziert auch noch ausreichen würde. Vielleicht kann da jemand ein Machtwort sprechen? Ich vermute fast, dass eigene Register bei größerer Byte-Anzahl den Geschwindigkeitsvorteil bieten. Bei Float-Operationen geht es sowieso nicht anders.

Das bringt mich zur Frage der unterstützten Datentypen. Ich würde tatsächlich vorschlagen, Typen bis zu 64 bit zu unterstützen (was dann ein 32-Byte-Stack-Fenster sinnvoll macht). Dann hätte man bis zu long und double-Typen auch drinnen, wobei ich vermute, dass double-Operationen ziemlich teuer wären. Der Flaschenhals wären dabei wohl am ehesten die Umwandlungs-Operationen binär-dezimal und umgekehrt. Das würde vermutlich einiges an Programmlänge für den Bytecode-Interpreter bedeuten.

Der wirklich riesige Vorteil wäre, dass man damit eine Menge moderner Sprachen zumindest rudimentär auf diese VM übersetzen könnte (natürlich per cross-Compiler, denn die entsprechenden Compiler wären für den C64 schlicht und einfach viel zu komplex).

Jeder Op-Code bekommt neben der Addressierungsart hineincodiert, wie groß seine Operanden sind, und weiß daher, wo auf dem Stack er sie findet. Soweit nötig, werden die in die entsprechenden Register kopiert, die entsprechende Routine aufgerufen, und das Ergebnis wieder abgeholt. Es fragt sich, wieviele Bit man dafür braucht. Ich vermute einmal 2-3 bits für die Addressierungsart, und weiters 2 oder 3 bits für die Operandengröße (1,2,4, ev. 8 müssen dargestellt werden). Macht zwischen 4 und 6 bits alleine dafür. Wir werden also sicher 2 Bytes pro Op brauchen. Man hätte sonst maximal 4 bits für die Operation selber, das sind 16 mögliche Instruktionen. Klingt extrem mager, würde ich sagen. Vielleicht gehts auf mit einem Byte, was einen entscheidenden Geschwindigkeitsvorteil und auch Vorteil für die Programm-Größe bedeuten würde, aber ich bin sehr skeptisch. Eventuell kann man eine Mischung hernehmen.

Die anderen Addressierungsarten benötigen wahlweise bis zu 2 Bytes mehr, wobei man 1 Byte für den Stack hernehmen könnte, und für die absolute Zero-Page-Addressierung (man könnte das ZP-Konzept eventuell ins virtuelle übernehmen, und auf den Stack genauso, also die ersten 256 Bytes vielleicht billiger addressieren. Aber das sind Details). Für die indirekte Addressierung ob absolut oder virtuell) wäre sowieso das oberste Stack-Element als Addresse zuständig.

So, hier unterbreche ich erst einmal, und mache morgen weiter.

(.. und fürchte schon die Reaktionen derer hier, die wirklich wissen, wovon sie schreiben!)

Zitat von BlondMammuth

Mir erscheinen intuitiv 16 oder 32 Bytes für dieses Fenster als vernünftig, und ich würde mir den Mechanismus so vorstellen: Der Stack wird in einem geschlossenen Kreislauf befüllt, und wenn neue Elemente gebraucht werden, werden 8 Bytes in einem auf den Stack "draussen" geschrieben, und im ZP-Fenster somit zum Überschreiben freigegeben. Sollte der Stack wieder geleert werden, werden sie wieder von draussen zurück geholt, und das immer in je 8(vielleicht auch 16?) Bytes-Portionen.

Das klingt so, als ob du Registerfenster neu erfinden willst.

Zitat

Diese Addressierungsmodi bräuchten aber nicht alle Befehle betreffen. Es würde ausreichen, wenn man damit bloß Werte in das lokale Stack-Fenster holen kann und von dort wieder hinausschreiben.

Eine Load/Store-Architektur ?

Zitat von Unseen

Das klingt so, als ob du Registerfenster neu erfinden willst.

Eher will ich sie adaptieren. Erfunden sind sie ja schon, wie du richtig bemerkt hast.

Zitat von Unseen

Eine Load/Store-Architektur ?

Soweit war ich noch gar nicht. Ich überlege mir halt, was auf die Schnelle sinnvoll wäre, und warte das Feedback ab. Obs dann genau das wird oder nicht, wird man sehen, wenns hinten rauskommt. Ich habe keine Berührungsängste mit bekannten Konzepten, aber auch keinen Drang, mich ihnen sklavisch zu unterwerfen.

Zitat von Stephan

Entschuldige bitte meine inkompetente Nachfrage, aber ich verstehe nur diese randständigen Aspekte

"Solls ein Diesel oder ein Benziner werden?" "Ruhe, ich tüftle grad an der Anzahl der Räder! Oder sollen wir lieber Tragflächen nehmen?"!

Aber konkret und ernsthaft: Ich bin eigentlich von einer Stack-Architektur ausgegangen, also sollte es vermutlich eher als oberstes Stack-Element dazu gepusht werden. Das wäre dann wohl eine 2-Address-Architektur. Andererseits - trotzdem danke für die Frage, denn eigentlich muss das für die anderen Addressierungsarten ja nicht unbedingt gelten. Fragt sich, ob man irgendwas an Performance gewinnt, wenn man eine 3-Address-Architektur verwendet. Vermutlich ein wenig, weil man Berechnungsergebnisse in manchen Fällen nicht mehr auf dem TOS zwischenspeichern würde, aber dann wären manche Instruktionen automatisch um 2 Bytes länger. Gut, dafür erspart man sich dann je eine STORE-Instruktion. Hm .. ehrlich gesagt, da bin ich noch gar nicht so schlüssig. Aber mehr als ein Brainstorming ist es ja eh noch nicht.

Zitat von Stephan

Ich kenne zuwenig "Paradigmen" von (aktuellen) Programmiersprachen und würde bei den Präferenzen anfangen nach "Bereichen" zu sortieren:

Bin dafür! Und was Paradigmen betrifft, stricke ich die am liebsten selber! Na, sagen wir so: Für die reine Lehre reicht in fast allen Fällen die HW ohnehin nicht aus, also nehmen wir einfach, was sich als praktisch anbietet, würde ich sagen.

Die Einteilung ist ein berechtigtes Anliegen. Soweit war ich noch nicht. Bei mir hat sich oben erst beim Schreiben rauskristallisiert, dass es sich um VM und Bytecode handelt. Es ist ja nochnicht viel mehr als "laute Selbstgespräche" aka "Brainstorming".

Zitat von Stephan

Zu den genannten kategorien hab ich schon gewisse Vorstellungen, muss mir aber erst zurechtlegen was mir sinnvoll erscheint.

Bitte nur zu! Und wenn sich was nachträglich als nachteilig erweist, auch kein Problem! Das wird noch oft genug passieren.

Ich habe übrigens auch einige Ideen dazu, die kommen noch. Ich werd gleich im Anschluss was zur Sprache posten, wie sie in meinem Kopf bisher entstanden ist.

Zur Sprache

Das wäre eine Sprache, die der Stack-Orientierung so weit wie möglich angepasst ist.

Ausdrücke

Ich nehme einmal an, ich habe Präfix-Ausdrücke (die kann man von "höheren" Sprachen aus als Infix-Ausdrücke darstellen, aber für die limitierten Edit-Fähigkeiten ist Präfix zur Umwandlung leichter).

Welche Operationen kann es im Code geben? Die üblichen Arithmetischen und Bitweisen Operationen und user-definierten Funktionen einerseits, und Konstanten andererseits. Wir hätten dann im Code auch Konstanten drin, die so, wie sie sind, auf den Stack gepusht werden. Typ und Größe müsste man entsprechend syntaktisch kenntlich machen (wie in BASIC mit "%" und "$", nur eben für Konstanten, und dabei müsste die Größe auch explizit irgendwie vermerkt werden). Das will noch durchdacht werden. Nehmen wir für den Augenblick ganz normale int oder sonstige Werte an:

Konstanten kann man dann quasi von rechts nach links auffassen, und in der Reihenfolge füllen sie den Stack auf. Also z.B.:

1 X 23 "Hallo"

wäre ein Ausdruck, der diese Werte (beim String eine Referenz) auf den Stack schreibt, wobei 1 der Top of Stack wäre. Das X würde für eine Variable stehen, deren Inhalt dorthin kopiert wird.

Dann kann man irgendwelche Operationen drauf anwenden, und weitere Elemenete erhalten. , wie z.B. in

+ 1 X 23 "Hallo"

Da würde

(1+X) 23 "Hallo"

rauskommen (also wenn X=3, wäre das .. 4 23 "Hallo").

Um auch Funktionen wie "first order citizens" (Bürger erster Klasse) behandeln zu können, kann man Beistriche verwenden. Bei Konstanten ergeben die noch keinen Unterschied, also wären

1 X 23 und 1, X, 23

dasselbe. Der Unterschied wird durch Funktionen sichtbar:

+ 1 X, 23 ==> 1+X, 23

aber

+, 1, X, 23 ==> +, 1, X, 23

Das "+" wird nicht evaluiert. Somit hätten wir mit dem Beistrich einen "Schutz" des Stacks symbolisiert. Allerdings kann es sein, dass man einer Funktion eine andere Funktion als ein Argument und noch ein paar übergeben möchte, z.B: F braucht 3 Argumente. Würde man dann schreiben:

F G, 1, X

würde das nicht funktionieren, weil F dann 1 und X gar nicht mehr übernimmt. Um das zu ermöglichen, benutzen wir runde Klammern:

F( G, 1, X )

was soviel bedeutet wie "die Ausdrücke innerhalb der Klammer kommen sich nicht in die Quere, aber F konsumiert sie alle trotzdem".

Was kommt aber heraus, wenn man doch nur F G, 1, X hinschreibt?

Das Ergebnis von F G ist eine Funktion, die noch zwei andere Argumente verlangt, denn eines hat sie ja schon. Das ist als "currying" bekannt, die Möglichkeit, Funktionen teilweise mit Argumenten zu versorgen. Umgekehrt kann es sein, dass man einer Funktion zuviele Argumente gibt. Dann bleiben die überzähligen Argumente auf dem Stack stehen.

Soweit zu den Ausdrücken, die man bilden kann. Dazu gibt es sicher noch mehr zu sagen, und das nächste wären Zuweisungen, Deklarationen, Definitionen, etc. - mehr dazu im nächsten Posting.

Lokale Variablen, Deklarationen, Zuweisungen

Nehmen wir das Stack-Modell aus den Ausdrücken weiter her, und bauen lokale Variablen ein. Die Syntax ist jetzt nicht wichtig, also nehme ich einmal die aus C-ähnlichen Sprachen (vielleicht wirds dann eine eher Pascal-artige, das soll jetzt nicht zu Konflikten führen):

Nehmen wir ein paar Deklarationen (und gleich auch Definitionen) vor:

int16 i=3, j=5;
int32 x=100 000;
char c='c';

Wie sieht der Stack jetzt aus? Diese Variablen haben ihre Plätze:

==> ( c='c', x=100 000, j=5, i=3)

Wie man sieht, liegen sie quasi verkehrt auf dem Stack, was auch logisch ist: Je älter, desto weiter unten/hinten auf dem Stack.

Und dann schreiben wir einen Ausdruck wie vorher hin:

+(i, j)

Wie sieht der Stack jetzt aus? Er enthält auf jeden Fall die vorher definierten Variablen, und danach den neuen Wert:

==> ( 8, c='c', x=100 000, j=5, i=3)

Nutzen wir diesen Ausdruck in einer Zuweisung:

x := * x - i j;

Diese Anweisung, auch den Ausdruck, muss man von links nach rechts lesen. Nehmen wir "loc" als den Zeiger auf das Ende der Deklarationen, und "top" als den Zeiger auf Top of Stack, dann kommt (in Pseudo-Code) etwa das heraus:

push16 (loc+7); push16 (loc+9); sub1616; push32 (loc+1); mult3216; pull32 (loc+1);

Oder, wenn man die Addition mit offset addressieren kann, wäre der Code erheblich kürzer:

sub1616 (loc+7) (loc+9); mult3216 (loc+3) (top); pull32 (loc+1);

Diese Variante hätte den Vorteil des kürzeren Codes, und wäre auf jeden Fall vorzuziehen, wenn man eigene Register für die Berechnungen einführt. Denn dann erspart man sich eine Menge Kopiererei.

Das Ergebnis wäre dieser Stack:

==> ( c='c', x=200 000, j=5, i=3)

Es ist eine offene Frage, ob man wirklich zwei Indizes (top, loc) verwendet, oder die entsprechenden Indizes einfach dazu zählt, wobei die zweite Variante den Nachteil hätte, dass man nicht beliebig (z.B. in Schleifen) pushen kann, weil statisch bekannt sein müsste, wie der Stack an einer bestimmten Stelle des Programms angewachsen ist. Darüber darf noch nachgedacht werde. Sicher ist, dass "top", und ggf. "loc", Registern in der virtuellen Maschine entsprechen müssen.

Von der Sprache her gesehen:

Eine Anweisung kann aus einem Ausdruck allein bestehen. Sobald sie jedoch mit Semikolon abgeschlossen wird, ist der Top of Stack ab da wieder wie vorher, d.h. was auch immer man durch irgendwelche Operationen oder Funktionen auf den Stack dazu "gepusht" hat, ist dann (zumindest offiziell) verloren.

Das entspricht weitgehend der ganz normalen Semantik, die man von Programmiersprachen generell gewohnt ist. Will man das verhindern, muss man den Ausdruck irgendwie im selben Statement (Anweisung) weiterverwenden.

Tupel

Tupel sind im Grunde mehrere Werte hintereinander, die man als einen betrachtet. Sie werden mit spitzen Klammern begrenzt. Die nächste Operation konsumiert sie alle. Z.B., wenn wir annehmen, wir wollten alles an eine bestimmte Addresse im Speicher schreiben. Nagelt mich jetzt nicht auf die Schreibweise fest, das kann sich noch ändern. Ich nehme inzwischen die C-Syntax für die Zahl, aber eine andere für die Pointer-Operation. Das A^ heißt sinngemäß: "Nimm diese Zahl als Ziel-Addresse für die Zuweisung", und ich erlaube casts im C-Stil, um den Typ anzugeben (das ist rein improvisiert und kann sich auch noch ändern):

0xD000^ := <(int8)47,(int16)11,(int16)4711,(int8)08,(int8)15,(int16)0815>;

Mit dieser Operation werden sämtliche Zahlen innerhalb der Klammern, wie sie auf dem Stack liegen, ab dem Speicherbereich 0xD000 abgelegt. Das wäre gleichbedeutend mit:

0xD000^ := (int8)47
0xD001^ := (int16)11
0xD003^ := (int16)4711;
0xD005^ := (int8)08;
0xD006^ := (int8)15;
0xD007^ := (int16)0815;

Ebenso kann man diese nutzen, um mehrern Variablen etwas zuzuweisen, was woanders liegt. Nehmen wir an, wir hätten an einer Adresse A verschiedene Werte hintereinander stehen, die wir in Variablen füllen wollen. Wir könnten das so tun:

<x, i, j, c> := A^;

Damit würde das, was in A steht, aufgespalten in Werte, die den Bytelängen der angegebenen Variablen entsprechen, und diese Variablen damit befüllt.

Übrigens könnte man diesen Mechanismus auch ähnlich wie "Data/Read" nutzen, wenn man ihn ein wenig aufbohrt. Er hat jedenfalls den Sinn, sich Kopier-Schleifen generell zu ersparen. Somit wird ihm sinnvollerweise auch eine Instruktion der virtuellen Maschine entsprechen.

Im den nächsten Postings will ich einerseits auf globale Definitionen eingehen, die im Rahmen so eines Programmiersystems eine ganz besondere Rolle auf mehrere Weisen spielen, andererseits auf Kontrollstrukturen. Schauen wir einmal, zu welchem Thema meine Gedanken schneller sind!

Danke für die Fragen!

Zitat von Stephan

Seh ich das richtig, dass bei deinen Tupeln alle Werte mit ihren zugehörigen Bezeichnernamen wie eine Hash-Tabelle auf dem Stack liegen? gar mit "=" als ASCII-Text als dritte Spalte dazwischen?

Nein, sondern als reine Bytes auf dem Stack. Die Namen sind zwar bekannt, solange man an dem Programm interaktiv bastelt, werden aber erstens extra verwaltet (nicht im Code, nicht auf dem Stack), und zweitens irgendwann, wenn man es zu reinem Bytecode verdichtet, zusammen mit vielen anderen Details, die zum Ablauf nicht nötig sind, entsorgt. Da kommt noch mehr dazu. Jedenfalls stehen die Namen für Variablen, und diese für ihre Positionen und Typen. Damit hat sich auch die Frage mit der Kopier-Orgie geklärt, nehme ich an?

Zitat von Stephan

Mir leuchtet nicht ganz ein, wieso ein auf Stack basierendes Konzept ausgerechnet für den 6502-Prozessor besonders geeignet sein soll, der sich doch durch einen kurz & kleingestutzten Mini-Stapel von 256 Bytes vom Vorgänger 6800 unterscheidet!

Die Antwort findet sich im Posting von 23. Mai 2017, 23:36, und zusammengefasst ist es so, dass es zwei viel größere und flexiblere Stacks gibt, einen Return- und einen Daten-Stack, wobei der Daten-Stack in einem Fenster in der ZP gespiegelt wird. Der interne 6510-Stack dient nur der VM zur Abarbeitung oder wird eben von reinen Maschinenprogrammen weiterhin genutzt.

Zitat von Stephan

OK, die Evaluierung von Ausdrücken ist besonders "stack-affin". Ich habe vage in erinnerung, dass Klammern, Punkt-Vor-Strich-Rechenregeln usw. am besten mit einem Stack gelöst oder soll man sagen, umschifft werden können. Auch bei der Optimierung. Irgendwo wird ein Baum "traversiert" und dann kann man auf wundersame Weise konstante Glieder rausziehen oder Dead-ends beseitigen etc.

Könnte man theoretisch überlegen, nur gehts hier um die on-Board-Programmierung, was bedeutet, dass die Umwandlung von lesbaren in Byte-Code besonders schnell und kurz sein sollte, also auch möglichst wenig Aufwand erfordern soll. Ich denke, da wären solche Optimierungen bereits gefährlich nahe an der Verschwendung. Allerdings - durchdenken schadet nichts. Vielleicht ist die Idee auch machbar. Wäre ein Alternativ-Vorschlag.

Zitat von Stephan

Aber generell hab ich mal gelernt, dass das meiste was in der Programmiererei rekursiv geschrieben werden kann, zu einer iterativen Lösung umgewandelt werden kann. (auch das Kopieren von Werten auf einen Software-Stack verursacht Aufwand, so um die 8 Zyklen pro Wert plus Schleifen-Overhead).

Definitiv. Dem entspricht in dem Fall die Tatsache, dass die Ausdrücke praktisch nur umgedreht werden müssen, um entsprechenden Code zu ergeben. Oder habe ich diese Anmerkung falsch verstanden? Meinst du den Befehl zum Kopieren von größeren Bereichen? Gut, den kann man ja in der VM beliebig implementieren.

Zitat von Stephan

Und dabei finde ich, sollte eine auf einem beschränkten 8-bit-Rechner lauffähige Hochsprache die Benutzerin den / Benutzer ermutigen ins Iterative zu gehen und das Rekursive eher in die 2. Reihe zu plazieren.

Gut, jetzt hast du mich ein wenig verloren. Wir sind noch gar nicht bei Schleifen etc, und auch nicht bei Rekursionen. Dahin komme ich erst. Aber vielleicht verstehe ich auch grade wirklich nicht, worum es dir geht. Vielleicht klärt sich das im Folgenden, vielleicht kommt aber eine Stelle, an der du mir es konkret erklären kannst.

Wieso die Festlegung auf 16kb ROM? Ein 64er sollte doch auch 24/32kb hingekommen, wie Atari XL oder CPC.

Funktionen und Kontroll-Strukturen

Blöcke sind Strukturen, die Anweisungen in Ausdrücke einschließen können. Grundsätzlich bildet man Blöcke duch eckige Klammern (vergleichbar den Geschweiften in C und ähnlichen Sprachen):

[ Anweisung; Anweisung; .. ]

ist ein Ausdruck, der dementsprechend einen Wert auf dem Stack hinterlässt. Will man eine Anweisung daraus machen, braucht es einen Strichpunkt dahinter. Will man einen ganz bestimmten Wert hinterlassen, nutzt man dazu das Schlüssenwort "return", wie in anderen Sprachen auch, nur dass es eben auch für Blöcke, und nicht nur für Funktionen Anwendung findet.

Grundsätzlich werden alle lokalen Variablen, die in Blöcken definiert werden, ausserhalb wieder "vergessen".

Beispiel:

[ return 3; ]

würde als Ausdruck den Wert 3 ergeben. Somit hätte der Gesamtausdruck

+ 5 [ return 3; ]

den Wert 8.

Ausdrücke haben eine weitere Eigenschaft: Sie können erfolgreich sein, oder schief gehen. In dem Fall bricht das Programm mit einer Ausnahme ab. Beispiel:

X >= 5;

verhält sich wie eine "Assertion", also bricht der Block ab, falls X kleiner 5 ist.

Funktionen sind zuerst einmal ganz normale Typen, und können ca. so geschrieben werden:

ArgumentAusdruck -> Resultatsausdruck

Dabei können die Argumente reine Variablen, oder auch Tupel mehrerer Variablen oder Ausdrücke sein. Es ist möglich, mehrere Funktionausdrücke zu kombinieren:

(Arg0 -> Res0) & (Arg1 -> Res1) & ..

Man kann solche Funktionsausdrücke Variablen zuweisen, dann hat man eine benannte Funktion. Beispiel:

fac := 0 -> 1
& 1 -> 1
& (int n) -> * n fac (- n 1);

(in dem Fall würde ich übrigens Stephan zustimmen, dass man das besser iterativ löst. Es ist hier auch nur als Beispiel für Funktionsausdrücke so dargestellt.)

Das läuft so ab:

fac 3 .. ( 0 = 3 -> 1 ) .. geht schief weil 0 nicht 3 ist
.. ( 1 = 3 -> 1 ) .. geht schief weil 1 nicht 3 ist
.. ( int n = 3 -> * n fac ( - n 1 ) ).. funktioniert weil n = 3 gesetzt werden kann
.. * 3 fac ( - 3 1 )
..* 3 fac 2
.. * 3 ( 0 = 2 -> 1 ) .. geht schief weil 0 nicht 2 ist

.. * 3 ( 1 = 2 -> 1 ) .. geht schief weil 1 nicht 2 ist

.. * 3 ( n = 2 -> * n fac ( - n 1 ) ) .. funktioniert weil n = 2 gesetzt werden kann
..* 3 * 2 fac ( - 2 1 ) )
..* 3 * 2 fac 1
..* 3 * 2 ( 0 = 1 -> 1 ) .. geht schief weil 0 nicht 1 ist
..* 3 * 2 ( 1 = 1 -> 1 ) .. funktioniert weil 1 1 ist
..* 3 * 2 1

fac 3 => 6

Funktionsausdrücke können so genutzt werden wie "case"-Statements in anderen Programmiersprachen. Beispiel:

( 1 -> ersterAusdruck ) &

( 2 -> zweiterAusdruck ) &

( n -> dritterAusdruck ) x

wäre in C ca. sowas:

Funktionsausdrücke können nicht nur mit Argumenten konstruiert werden, sondern auch mit dem Zustand eines Blocks. So beschreibt z.B.:

[ = x 1; ] -> 3

Wo ursprünglich die Gleichsetzung (nicht mit Zuweisung verwechseln!) einer Variable mit einem Argument steht, steht jetzt ein Block. Beide (Gleichsetzung und Block) können Ausnahmen hervorrufen (also schief gehen), und daher können beide in so einem funktionalen Ausdruck vorkommen.

Man kann man damit ein if then else darstellen:

( Bedingung -> If-Ausdruck ) & ( [] -> Else-Ausdruck )

wäre sinngemäß dasselbe wie

während ( Bedingung -> If-Ausdruck ) auch ohne "else"-Zweig möglich ist. Zuguterletzt kann man das Argument (oder den default-Wert) weglassen, wenn es nicht wichtig ist. Siehe

( Bedingung -> If-Ausdruck ) & ( -> Else-Ausdruck )

Schleifen werden durch zwei Anweisungen ermöglicht: repeat und return, die innerhalb von Blöcken sich immer auf den innersten Block beziehen.

Beispiel:

x := 1;
e := n;
[
[ = e 0 ] -> return;
x := * x n;
e := - e 1;
repeat
]

würde x = n hoch e berechnen.

Im Prinzip kann man damit bereits alle gängigen Kontroll-Strukturen erschlagen, aber man kann sich das syntaktisch erleichtern, und eigene Strukturen basteln. Darauf gehe ich noch ein.