Ich möchte euch mein Projekt 'BasicBeetle' vorstellen. Das ist ein Basic-programmierbares Computersystem. Bevor ich hier aber alles erkläre, schaut einfach auf www.DieProjektseite.de
Mein BasicBeetle
- Ersteller TKRoth
- Erstellt am
Hallo,
Basic-programmierbarer Atmel drin ? Also mit Interpreter. Bin ich jetzt stark der
Meinung ... Irgendwoher kommt mir das bekannt vor. Die ct fängt ja jetzt auch
mit Mikrocontrollern an. Ein Schachcomputer mit Atmel war auch in einer der
letzten elektors. Aber ich bin der Meinung ich hab da letztens irgendwo was mit
Basic in ner Zeitschrift gesehen ...
Soll jetzt aber keine Abwertung
sein
Gruß
Dino
ich könnte mich täuschen aber war da in einer der letzten elektors nicht ein
Basic-programmierbarer Atmel drin ? Also mit Interpreter. Bin ich jetzt stark der
Meinung ... Irgendwoher kommt mir das bekannt vor. Die ct fängt ja jetzt auch
mit Mikrocontrollern an. Ein Schachcomputer mit Atmel war auch in einer der
letzten elektors. Aber ich bin der Meinung ich hab da letztens irgendwo was mit
Basic in ner Zeitschrift gesehen ...
Soll jetzt aber keine Abwertungsein
Gruß
Dino
Hi Dino!
Und da ist es wieder.... unser wandelndes Lexikon... der Dino!
Mensch Dino, was du alles weißt. Hut ab!
Hallo TKRoth !
Ich habe mir die Projektseite von dir nur mal auf die Schnelle angesehen und muss sagen-----> Respekt!
Da hast du mal wieder eine Menge arbeit investiert!
Ich hätte es allerdings etwas schöner gefunden, wenn du hier im Projekte-Bereich des Forums nicht nur den Link präsentiert hättest.
OK, alles hier zu wiederholen wäre wohl zu viel verlangt.....
aber vielleicht eine kurze Beschreibung worum es geht.
Schöne Grüße,
Cassio
Und da ist es wieder.... unser wandelndes Lexikon... der Dino!
Mensch Dino, was du alles weißt. Hut ab!
Hallo TKRoth !
Ich habe mir die Projektseite von dir nur mal auf die Schnelle angesehen und muss sagen-----> Respekt!
Da hast du mal wieder eine Menge arbeit investiert!
Ich hätte es allerdings etwas schöner gefunden, wenn du hier im Projekte-Bereich des Forums nicht nur den Link präsentiert hättest.
OK, alles hier zu wiederholen wäre wohl zu viel verlangt.....
aber vielleicht eine kurze Beschreibung worum es geht.
Schöne Grüße,
Cassio
Hallo,
nochmal was texten ...
Ich hab mir das mal kurz durchgesehen. Das Teil lebt ja schon ne ganze Zeit
vor sich hin. Anfang mit 8032 wenn ich das so richtig gelesen hab. Das sind
schon ganz schön alte Dinger Ich hab hier mal mit nem 8049 gebastelt.
Ist aber auch schon so 10-15 Jahre her
Den ganzen Basic-Interpreter in Assembler gebaut ? Respekt ! Da steckt ne
Menge Arbeit drin. Mit Integer-Arithmetik könnte man das Teil also in etwa
mit nem ZX80 vergleichen. Bei Floating-Point mit nem ZX81. DieTeile waren
auch komplett in Assembler gebaut und ausgeknautscht bis zum geht nicht
mehr
Mit dem Auto-Loader kann man das Teil tatsächlich gut für ne Steuerung
verwenden, wenn Leute kein Programmiergerät haben. Einfach über RS232
das Proggi drauf und ins externe Flash packen. Das hat schon was ...
Den Interpreter (das System) gibts aber wohl nur im Prozessor gebrannt,
wenn ich das auf der Seite richtig interpretiert habe (34,90). Bei der Arbeit
aber auch irgendwie verständlich.
Hab ich mich da mit der elektor geirrt oder war das Teil da wirklich mal drin ?
Man liest und sieht so viel das man schnell man durcheinander kommt
Gruß
Dino
nochmal was texten ...
Ich hab mir das mal kurz durchgesehen. Das Teil lebt ja schon ne ganze Zeit
vor sich hin. Anfang mit 8032 wenn ich das so richtig gelesen hab. Das sind
schon ganz schön alte Dinger
Ich hab hier mal mit nem 8049 gebastelt.Ist aber auch schon so 10-15 Jahre her
Den ganzen Basic-Interpreter in Assembler gebaut ? Respekt ! Da steckt ne
Menge Arbeit drin. Mit Integer-Arithmetik könnte man das Teil also in etwa
mit nem ZX80 vergleichen. Bei Floating-Point mit nem ZX81. DieTeile waren
auch komplett in Assembler gebaut und ausgeknautscht bis zum geht nicht
mehr
Mit dem Auto-Loader kann man das Teil tatsächlich gut für ne Steuerung
verwenden, wenn Leute kein Programmiergerät haben. Einfach über RS232
das Proggi drauf und ins externe Flash packen. Das hat schon was ...
Den Interpreter (das System) gibts aber wohl nur im Prozessor gebrannt,
wenn ich das auf der Seite richtig interpretiert habe (34,90). Bei der Arbeit
aber auch irgendwie verständlich.
Hab ich mich da mit der elektor geirrt oder war das Teil da wirklich mal drin ?
Man liest und sieht so viel das man schnell man durcheinander kommt
Gruß
Dino
Moin TKRoth!
Ich habe mir dein Prokjekt auch noch mal angesehen....
Ist wirklich interssant und wie Dino schon schrieb, steckt da eine Menge Arbeit drin.
Entweder habe ich nicht alles richtig gefunden, oder deine "Haupteinheit" des BasicBeetle gibt es wirklich nur käuflich zu erwerben.
Alle weiteren Beschreibungen beziehen sich immer auf das fertige Modul und dessen Programmierung.
Da es HIER im Projekte-Bereich des Forums um User Projekte incl. nachvollziehbarer Entwicklung der Hard- und Software geht denke ich, wäre dein Basic-Käfer wohl besser im "Biete-Bereich" aufgehoben.
Schließlich kann man das Grundmodul nur fertig erwerben und ich gehe mal nicht davon aus, dass du hier den vollständigen Code des "Käfers" noch einstellen möchtest.
Ungeachtet dessen..... Hut ab, für das Projekt!
Gruß,
Cassio
Ich habe mir dein Prokjekt auch noch mal angesehen....
Ist wirklich interssant und wie Dino schon schrieb, steckt da eine Menge Arbeit drin.
Entweder habe ich nicht alles richtig gefunden, oder deine "Haupteinheit" des BasicBeetle gibt es wirklich nur käuflich zu erwerben.
Alle weiteren Beschreibungen beziehen sich immer auf das fertige Modul und dessen Programmierung.
Da es HIER im Projekte-Bereich des Forums um User Projekte incl. nachvollziehbarer Entwicklung der Hard- und Software geht denke ich, wäre dein Basic-Käfer wohl besser im "Biete-Bereich" aufgehoben.
Schließlich kann man das Grundmodul nur fertig erwerben und ich gehe mal nicht davon aus, dass du hier den vollständigen Code des "Käfers" noch einstellen möchtest.
Ungeachtet dessen..... Hut ab, für das Projekt!
Gruß,
Cassio
Hallo TKRoth,
also das mit dem Quellcode kann ich verstehen. Immerhin stecken das so um
die 10 Jahre Arbeit drin wenn ich das in der Historie richtig mitbekommen habe.
Wär aber trotzdem mal interessant wenn Du einfach mal die Funktionsblöcke
grob erklärst wie du das angestelllt hast. Also wie das Teil grob intern
arbeitet. Dafür brauchst du den Quellcode oder Teile daraus ja nicht preisgeben.
Nur damit man mal nen Überblick bekommt.
Ich hab damals auf meinem ZX Spectrum auch mal nen Z80-Assembler
zusammengebastelt. Ohne Vorkenntnisse wie so ein Assembler oder Compiler
eigentlich innen drin arbeiten. Das komplizierteste war dabei der Parser für
den Quellcode, der die Zeilen zerlegt hat und sich um die Sprungmarken und
andere Sachen (Macros, Aliase, ...) gekümmert hat. Ich hab dafür damals
2 Durchläufe benötigt.
- 1. Durchlauf ... alle Labels, Variablen, Aliase, Macros raussuchen und in einer Verwaltungsstruktur anlegen
- 2. Durchlauf ... der eigentliche Assemblerlauf der den Binärcode erzeugt hat
Aber es lief
Wär echt interessant. Würde mich schon alleine darum interessieren um mal
einen Einblick zu bekommen an was man alles denken und um was man sich
kümmern muß. Nachprogrammieren werd ich das sowieso nicht. Hab ich viel
zu wenig Zeit für. Ich wär schon froh, wenn ich mit meinen Projekten weiter
kommen würde Aber man lernt ja gerne dazu ...
Gruß
Dino
also das mit dem Quellcode kann ich verstehen. Immerhin stecken das so um
die 10 Jahre Arbeit drin wenn ich das in der Historie richtig mitbekommen habe.
Wär aber trotzdem mal interessant wenn Du einfach mal die Funktionsblöcke
grob erklärst wie du das angestelllt hast. Also wie das Teil grob intern
arbeitet. Dafür brauchst du den Quellcode oder Teile daraus ja nicht preisgeben.
Nur damit man mal nen Überblick bekommt.
Ich hab damals auf meinem ZX Spectrum auch mal nen Z80-Assembler
zusammengebastelt. Ohne Vorkenntnisse wie so ein Assembler oder Compiler
eigentlich innen drin arbeiten. Das komplizierteste war dabei der Parser für
den Quellcode, der die Zeilen zerlegt hat und sich um die Sprungmarken und
andere Sachen (Macros, Aliase, ...) gekümmert hat. Ich hab dafür damals
2 Durchläufe benötigt.
- 1. Durchlauf ... alle Labels, Variablen, Aliase, Macros raussuchen und in einer Verwaltungsstruktur anlegen
- 2. Durchlauf ... der eigentliche Assemblerlauf der den Binärcode erzeugt hat
Aber es lief
Wär echt interessant. Würde mich schon alleine darum interessieren um mal
einen Einblick zu bekommen an was man alles denken und um was man sich
kümmern muß. Nachprogrammieren werd ich das sowieso nicht. Hab ich viel
zu wenig Zeit für. Ich wär schon froh, wenn ich mit meinen Projekten weiter
kommen würde
Aber man lernt ja gerne dazu ...Gruß
Dino
Ich kann ja mal versuchen, ob ich die Funktionsweise ein wenig beschrieben bekomme.
Das System besteht im Grunde aus 3 großen Programmteilen: Den Parser, den Executer und den Parametrisierer (Wie ich ihn nenne ).
Im Direktmodus befindet man sich erst einmal in einer rel. einfachen Input-Routine. Wird die eingegebene Zeile abgeschickt wird diese dem Parser übergeben.
Dieser fängt nun an die Zeile zu zerhacken. Hierzu wird nach Trennzeichen gesucht (Leerzeichen, Doppelpunkt, Komma, Semikolon, Klammer usw.). So wird dann ein Zeilen-Segment abgetrennt. Nun wird in mehreren Tabellen gesucht, ob es dieses Segment dort gibt, also ob es ein Befehl, eine Funktion, ein Operator oder eine Verknüpfung ist. Wenn ja, wird das Token erstellt und in die ausführbare Zeile kopiert. Wird das Segment in keiner Tabelle gefunden, wird versucht dieses als Zahl zu konvertieren. Geht dies, liefert die Konvertierroutine die Zahl mit einer Typkennzeichnung (Dez, Hex, Bin) zurück. Diese wird dann in die Zeile kopiert. Schlägt auch dies fehl, geht der Parser von aus, es ist ein Element was erst zur Laufzeit festgelegt (Variable oder Portzuweisung z.B.) wird und speichert es einfach so ab. Sonderzeichen werden einfach so kopiert.
Ist die Zeile komplett übersetzt, geht es weiter zum Executer. Dieser schaut erst einmal nach, ob eine ihm eine Programmzeile angeboten wird. Wenn ja, wird der Speicher durchwühlt, ob diese Zeile schon vorhanden ist. Wenn ja, schmeisst der Executer die raus und verrückt den oberen Teil des aktuellen Programms soweit, dass die neue Zeile reinpasst. Dann wird die Zeile reinkopiert.
Ist die Zeile noch nicht vorhanden, wird geprüft, ob die Zeilennummer größer als alle anderen Zeilen ist. Wenn ja, wird einfach die Zeile hinten 'drangeklatscht'. Muss diese in ein Prigramm eingefügt werden, wird wieder eine Lücke geschaffen und die Zeile eingefügt.
Ein Sonderfall ist es, wenn nur eine Zeilennummer eingegeben wurde. Dann wird die Zeile, die man eingegeben hat, gelöscht, wenn sie gefunden hat. Wenn sie nicht da ist, auch egal.
Finder der Executer keine Zeilennummer, weiß er, dass er diese Zeile ausführen soll. Hier wird dann geschaut, ob ein Befehls-Token vorhanden ist. Wenn ja, wird der Tokencode in der Sprungtabelle gesucht und angesprungen.
Der Befehl nun benötigt unter Umständen Parameter. Hier wird ein Kontrollbyte generiert in dem steht, welche Datentypen der aufrufende Befehl erwartet. Nun wird der Paramtrisierer aufgerufen. Dieser schaut dann ob in der Programmzeile nun eine Zahl, String oder eine Funktion folgt. Folgt eine Zahl wird anschließend geprüft, ob eine Verknüpfung folgt. Wenn ja, wird sich das aktuelle gemerkt und wieder zum Anfang der Routine gesprungen ob zu schauen ob wieder eine Zahl, Funktion oder ein Operand folgt. Diese wird dan ausgelesen oder ausgeführt. Anschließend wird das alte Ergebnis mit der jetzt gewonnen Zahl genommen und geschaut, wie die beiden miteinander verknüpft werden sollen, was dann entsprechend auch getan wird. Folgt nun keine weitere Verknüpfung etc. wird der Ergebnistyp mit dem geforderten Typ abgeglichen. Passt es, wird der Wert zurück gegeben. Wenn nicht: 'Type missmatch'
Wurde nun eine Zeile so komplett abgearbeitet, schaut der Executer, ob er sich im Direktmodus befindet. Wenn ja, gehts zurück zur Eingaberoutine, welche das allseits bekannte und beliebte 'Ready' ausgiebt und auf die nächste Eingabe wartet.
Befindet er sich im Programmodus, werden die Daten der neuen Zeile geholt, die aktuelle Zeilennummer für evtl. spätere Verwendung gespeichert (z.B. Fehlermeldung) und übersprungen. Dann wird die Zeile wie oben ausgeführt.
Findet sich keine neue Programmzeile, wird wieder auf Direktmodus umgeschaltet und ... Siehe weiter oben
Hoffe, das es ein wenig Licht reinbringt. Aber, wie so oft, der Teufel steckt im Detail. Wenn ich nur an die Entwicklung des Every-Befehls denke ... Ständig gab es Abstürze oder komplettes Choas, weil er sich dauernd 'verschluckt' hat.
Das System besteht im Grunde aus 3 großen Programmteilen: Den Parser, den Executer und den Parametrisierer (Wie ich ihn nenne
).Im Direktmodus befindet man sich erst einmal in einer rel. einfachen Input-Routine. Wird die eingegebene Zeile abgeschickt wird diese dem Parser übergeben.
Dieser fängt nun an die Zeile zu zerhacken. Hierzu wird nach Trennzeichen gesucht (Leerzeichen, Doppelpunkt, Komma, Semikolon, Klammer usw.). So wird dann ein Zeilen-Segment abgetrennt. Nun wird in mehreren Tabellen gesucht, ob es dieses Segment dort gibt, also ob es ein Befehl, eine Funktion, ein Operator oder eine Verknüpfung ist. Wenn ja, wird das Token erstellt und in die ausführbare Zeile kopiert. Wird das Segment in keiner Tabelle gefunden, wird versucht dieses als Zahl zu konvertieren. Geht dies, liefert die Konvertierroutine die Zahl mit einer Typkennzeichnung (Dez, Hex, Bin) zurück. Diese wird dann in die Zeile kopiert. Schlägt auch dies fehl, geht der Parser von aus, es ist ein Element was erst zur Laufzeit festgelegt (Variable oder Portzuweisung z.B.) wird und speichert es einfach so ab. Sonderzeichen werden einfach so kopiert.
Ist die Zeile komplett übersetzt, geht es weiter zum Executer. Dieser schaut erst einmal nach, ob eine ihm eine Programmzeile angeboten wird. Wenn ja, wird der Speicher durchwühlt, ob diese Zeile schon vorhanden ist. Wenn ja, schmeisst der Executer die raus und verrückt den oberen Teil des aktuellen Programms soweit, dass die neue Zeile reinpasst. Dann wird die Zeile reinkopiert.
Ist die Zeile noch nicht vorhanden, wird geprüft, ob die Zeilennummer größer als alle anderen Zeilen ist. Wenn ja, wird einfach die Zeile hinten 'drangeklatscht'. Muss diese in ein Prigramm eingefügt werden, wird wieder eine Lücke geschaffen und die Zeile eingefügt.
Ein Sonderfall ist es, wenn nur eine Zeilennummer eingegeben wurde. Dann wird die Zeile, die man eingegeben hat, gelöscht, wenn sie gefunden hat. Wenn sie nicht da ist, auch egal
. Finder der Executer keine Zeilennummer, weiß er, dass er diese Zeile ausführen soll. Hier wird dann geschaut, ob ein Befehls-Token vorhanden ist. Wenn ja, wird der Tokencode in der Sprungtabelle gesucht und angesprungen.
Der Befehl nun benötigt unter Umständen Parameter. Hier wird ein Kontrollbyte generiert in dem steht, welche Datentypen der aufrufende Befehl erwartet. Nun wird der Paramtrisierer aufgerufen. Dieser schaut dann ob in der Programmzeile nun eine Zahl, String oder eine Funktion folgt. Folgt eine Zahl wird anschließend geprüft, ob eine Verknüpfung folgt. Wenn ja, wird sich das aktuelle gemerkt und wieder zum Anfang der Routine gesprungen ob zu schauen ob wieder eine Zahl, Funktion oder ein Operand folgt. Diese wird dan ausgelesen oder ausgeführt. Anschließend wird das alte Ergebnis mit der jetzt gewonnen Zahl genommen und geschaut, wie die beiden miteinander verknüpft werden sollen, was dann entsprechend auch getan wird. Folgt nun keine weitere Verknüpfung etc. wird der Ergebnistyp mit dem geforderten Typ abgeglichen. Passt es, wird der Wert zurück gegeben. Wenn nicht: 'Type missmatch'
Wurde nun eine Zeile so komplett abgearbeitet, schaut der Executer, ob er sich im Direktmodus befindet. Wenn ja, gehts zurück zur Eingaberoutine, welche das allseits bekannte und beliebte 'Ready' ausgiebt und auf die nächste Eingabe wartet.
Befindet er sich im Programmodus, werden die Daten der neuen Zeile geholt, die aktuelle Zeilennummer für evtl. spätere Verwendung gespeichert (z.B. Fehlermeldung) und übersprungen. Dann wird die Zeile wie oben ausgeführt.
Findet sich keine neue Programmzeile, wird wieder auf Direktmodus umgeschaltet und ... Siehe weiter oben
Hoffe, das es ein wenig Licht reinbringt. Aber, wie so oft, der Teufel steckt im Detail. Wenn ich nur an die Entwicklung des Every-Befehls denke ... Ständig gab es Abstürze oder komplettes Choas, weil er sich dauernd 'verschluckt' hat.
@Dino: Was du geschrieben hast ist ein so genannter 2-Pass-Assembler. Das ist auch die gängige Praxis. Es gibt auch 1-Pass Assembler. Hier wird jedes mal, wenn ein unbekanntes Label etc. auftaucht, die Position gespeichert und am Ende des Assembler-Vorganges nachgeschaut, wo noch Adressen von Sprungmarken etc. nachgetragen werden müssen. Dadurch, dass das Nachtragen ja um einiges schneller geht, als die Mnemonics etc. erneut zu übersetzen, ist ein 1-Pass-Assembler auch deutlich schneller. Nachteil: Bei 1-Pass braucht man teilweise noch einmal soviel Speicher, wie der eigentliche Objekt-Code. Dadurch ist 1-Pass für kleinere Rechner mit rel. wenig RAM eher ungeeignet.
Hallo,
Kann ich dann ja mal über nen Scanner mit OCR laufen lassen und hier im
Off-Topic-Bereich reinstellen Ist aber wie gesagt schon einiges
älter Gebrauchen kann man das sowieso nicht mehr. Das waren neben
einem selbst geschriebenem Texteditor die ersten größeren Programme die
man selber zusammengedreht hat. Der Assembler hat die Mnemonics anhand
von Tabellen dann in Binärcode umgesetzt. Da war nichts mehr zwischengeschaltet.
War eine Sch...Arbeit die ganzen Mnemonics in Tabellenform reinzuhacken.
Beim Z80 waren das glaube ich so 5-7 Tabellen mit jeweils 256 Befehlen die
aber nicht lückenlos besetzt waren. Die Tabellen wurden dann mit Steuercodes
umgeschaltet (0xED 0xBD oder sowas ...)
Edit: Mal kurz die Command-Summary vom Z80 durchgesehen ...
So wie es aussieht waren das 0xED , 0xEB , 0xDB , 0xDD , 0xDDCB , 0xFDCB
um in die anderen Befehlstabellen zu kommen. Also mit der Basistabelle dann
insgesamt 7 Befehlstabellen mit jeweils maximal 256 Befehlen. Manche Tabellen
hatten nur IO-Befehle und manche nur Bitmanipulator-Befehle.
Gruß
Dino
mal sehen ob ich die Papierrolle mit dem Basic-Code noch finde
Kann ich dann ja mal über nen Scanner mit OCR laufen lassen und hier im
Off-Topic-Bereich reinstellen
Ist aber wie gesagt schon einigesälter
Gebrauchen kann man das sowieso nicht mehr. Das waren neben einem selbst geschriebenem Texteditor die ersten größeren Programme die
man selber zusammengedreht hat. Der Assembler hat die Mnemonics anhand
von Tabellen dann in Binärcode umgesetzt. Da war nichts mehr zwischengeschaltet.
War eine Sch...Arbeit die ganzen Mnemonics in Tabellenform reinzuhacken.
Beim Z80 waren das glaube ich so 5-7 Tabellen mit jeweils 256 Befehlen die
aber nicht lückenlos besetzt waren. Die Tabellen wurden dann mit Steuercodes
umgeschaltet (0xED 0xBD oder sowas ...)
Edit: Mal kurz die Command-Summary vom Z80 durchgesehen ...
So wie es aussieht waren das 0xED , 0xEB , 0xDB , 0xDD , 0xDDCB , 0xFDCB
um in die anderen Befehlstabellen zu kommen. Also mit der Basistabelle dann
insgesamt 7 Befehlstabellen mit jeweils maximal 256 Befehlen. Manche Tabellen
hatten nur IO-Befehle und manche nur Bitmanipulator-Befehle.
Gruß
Dino
Der Z80 hatte über 700 Befehle. Ich habe noch irgendwo die handgeschriebene Tabelle mit sämtlichen Befehlen. Aber wenn man sich einmal dran setzt und eine Tabelle anfertigt, wieviel Befehle ein AVR hat ...
Alleine z.B. der MOV-Befehl:
mov r0,r0
mov r0,r1
mov r0,r2
mov r0,r3
...
mov r31,r31
Alleine z.B. der MOV-Befehl:
mov r0,r0
mov r0,r1
mov r0,r2
mov r0,r3
...
mov r31,r31
Da kommen auch etliche Hundert zusammen
es gibt ja dazu dann auchnoch die ST- und LD-Befehle mit Pre- und Post- Decrement/Increment und
was weiß ich noch ...
Das sind noch etliche mehr als beim Z80. Da hatsich doch schon einiges getan
Das schöne ist auch das man sich beim AVR die ganze Bus-Bastelei mit dem
SRAM, EEPROM, PIO, SIO, CTC, ... sparen kann
Erleichtert die Arbeitungemein
Gruß
Dino
Das stimmt. Wenn ich mir den Schaltplan vom 8032-'BasicBeetle' ansehe und den jetzigen ... Geschweige denn den Geschwindigkeitzunterschied.
Frequenzmesser bis 5 kHz (Zählermodul bis 100 MHz bereits in Planung ) in Basic geschrieben, wäre beim 8032 undenkbar, geschweige denn bei meinem ersten Computer, einen Schneider CPC 464.
Frequenzmesser bis 5 kHz (Zählermodul bis 100 MHz bereits in Planung
) in Basic geschrieben, wäre beim 8032 undenkbar, geschweige denn bei meinem ersten Computer, einen Schneider CPC 464.
Hallo,
ich hab mir deine Erklärung vom Interpreter mal auf nem Blatt aufgezeichnet
und im Kopf durchgespielt. Alles recht interessant
- Parser ...
zerlegt die Zeilen und wandelt den ASCI-Text in Befehls-Token (zB 0x62 für PRINT)
und für den Paarametrisierer verwertbare Daten (Zahlen, Strings, ...) um
und liefert die umgewandelte Zeile an den Executer.
- Executer ...
nimmt den Befehls-Token als Index für eine Tabelle in der die Routinen für die
einzelnen Befehle vermerkt sind und angesprungen werden. Außerdem schubst
er den Parametrisierer an, die Daten, die für den Befehl benötigt werden aus
der gewandelten Zeile zu holen und zu verarbeiten bis sie der Befehlsroutine
schmecken oder es einen Fehler gibt.
- Parametrisierer ...
das "Rechenwerk" das die Daten addiert, subtrahiert, Strings zerlegt, Daten
zusammenfügt, ... kurz gesagt - die Argumente hinter dem Befehl verarbeitet.
Stimmt das soweit wie ich das verstanden habe?
Ist schon recht interessant so einen Interpreter mal in die Innereien zu
schauen
Wenn mich mal der Hafer sticht kann ich sowas ja in den Büchern
ZX81-ROM und ZX-Spectrum-ROM nachlesen wie das dann im Code in
etwa gemacht wird. Aber da muß ich mich schon ziemlich langweilen
bis ich das mache
Gruß
Dino
ich hab mir deine Erklärung vom Interpreter mal auf nem Blatt aufgezeichnet
und im Kopf durchgespielt. Alles recht interessant
- Parser ...
zerlegt die Zeilen und wandelt den ASCI-Text in Befehls-Token (zB 0x62 für PRINT)
und für den Paarametrisierer verwertbare Daten (Zahlen, Strings, ...) um
und liefert die umgewandelte Zeile an den Executer.
- Executer ...
nimmt den Befehls-Token als Index für eine Tabelle in der die Routinen für die
einzelnen Befehle vermerkt sind und angesprungen werden. Außerdem schubst
er den Parametrisierer an, die Daten, die für den Befehl benötigt werden aus
der gewandelten Zeile zu holen und zu verarbeiten bis sie der Befehlsroutine
schmecken oder es einen Fehler gibt.
- Parametrisierer ...
das "Rechenwerk" das die Daten addiert, subtrahiert, Strings zerlegt, Daten
zusammenfügt, ... kurz gesagt - die Argumente hinter dem Befehl verarbeitet.
Stimmt das soweit wie ich das verstanden habe?
Ist schon recht interessant so einen Interpreter mal in die Innereien zu
schauen
Wenn mich mal der Hafer sticht kann ich sowas ja in den Büchern
ZX81-ROM und ZX-Spectrum-ROM nachlesen wie das dann im Code in
etwa gemacht wird. Aber da muß ich mich schon ziemlich langweilen
bis ich das mache
Gruß
Dino
Im Groben hast du es richtig erkannt. Gibt natürlich noch diverse Feinheiten. Aber das würde dann auch zuweit führen. Ich habe mich schon immer für Interpreter und/oder Compiler interessiert.
Was die Innereien vom Beetle angeht, da werde ich noch Vieles in meinem neuen Buch erklären, was ich schreibe.
Was die Innereien vom Beetle angeht, da werde ich noch Vieles in meinem neuen Buch erklären, was ich schreibe.
Hallo,
Compiler oder Interpreter bauen werde lohnt es sich für mich, da bis in die
Feinheiten reinzugehen. Aber die groben Zusammenhänge interessieren mich
schon , da man die ja evtl wieder bei anderen Sachen wieder einsetzen kann.
zu verwenden oder Lösungsmöglichkeiten aufgezeigt zu bekommen. Aber so
interessant es auch sein mag lohnt sich das Buch wohl für mich nicht. Ich
wünsch dir aber auf jeden Fall viel Erfolg damit.
Meine Interessen liegen mehr in anderen Bereichen. Aber so richtig in eine
Richtung bringen kann ich sie auch nicht. Dafür sind sie doch zu vielfältig.
Gruß
Dino
ist schon interessant wie das intern zusamenhängt. Da ich aber wohl nie einen
Compiler oder Interpreter bauen werde lohnt es sich für mich, da bis in die
Feinheiten reinzugehen. Aber die groben Zusammenhänge interessieren mich
schon , da man die ja evtl wieder bei anderen Sachen wieder einsetzen kann.
Wär schon interessant es durchzulesen um für andere Projekte Teile daraus
zu verwenden oder Lösungsmöglichkeiten aufgezeigt zu bekommen. Aber so
interessant es auch sein mag lohnt sich das Buch wohl für mich nicht. Ich
wünsch dir aber auf jeden Fall viel Erfolg damit.
Meine Interessen liegen mehr in anderen Bereichen. Aber so richtig in eine
Richtung bringen kann ich sie auch nicht. Dafür sind sie doch zu vielfältig.
Gruß
Dino
In der Elektor war wirklich mal sowas drin!
Ist aber nicht mit dem Beetle zu vergleichen! - und da sprech ich aus Erfahrung!
@TK
Wann soll denn das Buch erscheinen?
Ich weiß du hast gerade noch andere Sachen zu tun!
Inzwischen ist auch das Logikus-Programm (Logikanalysator/Logikprüfer) auf www.DieProjektseite.defertig.