doku? gibts nicht. organisation des infoblocks: 1. accesslevel 2. name 3. clearcache 4. cachename hier der text, den ich zum entwurf verwendet habe. eher veraltet: Programmfestspeicher ==================== Vorerst einfach auf Festplatte in einem Verzeichnis. Datenfestspeicher ================= Noch garnicht, später vielleicht auch Festplatte, oder mysql, oder wie auch immer. Datenarbeitsspeicher ==================== Doppelt verkettete Liste, jedes Element kann zusätzlich einen Namen haben. Zugriff entweder durch push/pop bzw. shift/unshift, über eine Nummer wie bei einem Array oder über seinen Namen wie bei einem Hash. Es ist aber auch möglich, direkt über einen Pointer zuzugreifen. Pointer lassen sich jedoch nicht vom Benutzer direkt erstellen, sondern nur von entsprechend priviligierten Programmen. Im ersten Entwurf würde man Elemente, auf die per Nummer oder Namen zugegriffen wird, durch naive Suche finden. Später kann man ja noch einen Index oder ähnliches drauf setzen. Diese Speicherstruktur nenne ich "vector". Datentypen: Nach Außen hin sollen nur wenige verschiedene Datentypen sichtbar sein: - Wert (integer, string, was auch immer) - Vector Wert wird intern in mehrere subtypen unterteilt, die jedoch automatisch bei Bedarf konvertiert werden: - int - float - string, bzw. pointer auf string - pointer auf Elemente eines Vektors Aus technischer Sicht gibt es nach Außen hin eigentlich auch nicht die Unterscheidung zwischen Wert und vector. Auch hier kann und wird bei Bedarf eine automatische Konvertierung vorgenommen. Im Normalfall wird jedoch der Anwender dies nicht tun, und in der Dokumentation wird auch immer ein klarer Unterschied zwischen normalen Werten und Vektoren gemacht. Ein Sonderfall ist der Pointer auf Elemente eines Vektors: Weder kann von einem Wert in diesen Typ konvertiert werden, noch anders herum (bzw. doch, aber dann käme nur ein String "pointer" oder 0 bei heraus). Die einzelnen Elemente eines Vektors werden in einem union gespeichert. Der Union enthält die verschiedenen möglichen Ausprägungen der Werte, also int, float, und pointer. Zudem gibt es ein Feld, in dem gespeichert wird, welche Ausprägung gerade "aktiv" ist. Ein zusätzlicher Typ, den man später noch hinzufügen könnte wäre "array". Dieser Typ würde sich zum Speichern größerer Datenmengen eignen, da er gegenüber einem Vektor keinen Overhead pro Element hätte. Programmarbeitsspeicher ======================= Der Programmspeicher ist nichts anderes als normaler Datenspeicher. Dies macht es möglich, Compilererweiterungen selbst in botforth zu schreiben. minibotforth ============ Folgende Befehle müssen implementiert werden: - swap - + ... minibotforth sollte so extrem simpel sein, daß man es später vielleicht sogar ganz weg lassen kann, um direkt nach Maschinensprache zu kompilieren. Compiler von botforth nach minibotforth ======================================== 1. Schritt: lexikalische analyse, also erkennen der einzelnen schluesselworte usw. Hier wird zwar erkannt, was ein Befehl ist, aber noch nicht, ob der Befehl intern oder extern vorliegt. Jeder Befehl wird als Node vom Typ BF_TYPE_C_TEXT gespeichert, wobei der Befehlsname in Klartext als String abgelegt wird. 2. Schritt: Compiler. Hier wird botforth nach minibotforth gewandelt. Auch hier werden jedoch Befehlsnamen als BF_TYPE_C_TEXT abgelegt. 3. Ausführung: Erst während der Programmausführung, also wenn wir uns schon längst nicht mehr im Compilermodus befinden, werden Befehle vom Typ BF_TYPE_C_TEXT, sobald sie ausgeführt werden sollen, in BF_TYPE_C_INT bzw. BF_TYPE_C_EXT gewandelt. Dies dient dazu, den Compiler vom User erweiterbar zu halten. Er kann so leicht Befehle einfügen, ohne mit Pointern etc. rumspielen zu müssen. Somit wird auch kein Sicherheitsloch erzeugt. Aus der Sicht eines Anwenders, der den Compiler durch das Programmieren von Compilezeitverhaltens von Befehlen erweitern will, sind Befehle quasi wie Strings zu handhaben.