mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Basic Interpreter


Autor: Johannes Zinnau (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Es gibt ja für den 8051 nen Basic Interpreter (Tiny Basic) gibt es so
etwas ähnliches auch für die neuen Atmel Chips?

Autor: Thorsten (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: Johannes Zinnau (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das kenn ich schon. Ich suche aber etwas das auf dem Chip Läuft. Tiny
Basic konnte man z.B. über ein Terminal uber den seriellen Port
bedienen.

Autor: AxelR. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Johannes,
was heisst konnte?!? Ich habe das Ding immernoch - läuft langsam, aber
läuft!
Gruß
Axel

Autor: Johannes Zinnau (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja klar kann es das noch war bei mir aber ne weile her als ich das dass
letzte mal genutzt habe. So war das gemeint.

Hab das teil auch noch hier rumliegen.

Autor: AxelR. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ich habe ihn beim Umzug gefunden, sonst wüsste ich nicht mal, das ich
das gute Teil noch besitze.
Aber gut, tut nichts zur Sache...

Autor: thkais (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Diese Anfrage gab es schon öfters - vielleicht kann man sich ja
zusammentun, und so etwas schreiben? Angedacht hatte ich so etwas schon
öfters, aber immer wieder aus zeitgründen verworfen.
Ein Interpreter ist eigentlich kein Hexenwerk, allerdings als
"Hobby"-Projekt schon ein wenig groß für eine einzelne Person.
Zutrauen würde ich mir das schon, aber Zeit hätte ich nicht...
Ich habe gerade aktuell auch das MCS-51 Basic wieder ausgegraben, genau
aus dem Grund, weil man es eben vor Ort ohne PC und Flash-Upload direkt
benutzen kann. Allerdings hat es den einen, großen Makel: Es ist
wirklich langsam. Die Hauptursache sehe ich darin, daß alle Variablen
grundsätzlich als Float definiert sind, da wäre einiges Potential, wenn
man Integer implantieren könnte.
Nächstes Problem bei einer solchen Lösung: Wohin mit dem Code? Ähnlich
wie bei der C-Control in einem I2C-EEProm wäre zwar elegant, würde
wieder einiges an Geschwindigkeit kosten (man könnte mit der
Hardware-TWI einiges herausholen, Prefetch usw.) oder ins Flash, das
bei den Selbstprogrammierbaren eigentlich auch kein Problem wäre.
Bleiben die Laufzeitvariablen, die müssen natürlich in den internen RAM
- und da kann es eng zugehen. Ein Compiler kann da von vornherein
einiges optimieren, ein Interpreter muß auf Speed optimiert werden und
man hat nicht die Rechenpower eines PC im Genick. Da ließe sich evtl.
beim Tokenizer etwas machen. Der nächste Punkt: Benennung von
Variablen. Da der Name von Variablen im Quelltext steht, ist natürlich
klar, daß sie zwecks Speicherersparnis möglichst kurz sein müssen - das
wiederum ist der Lesbarkeit abträglich. Und es ist nicht unbedingt
wünschenswert, daß der Interpreter ausschließlich im Mega-128 lauffähig
ist... Eine Alternative wäre das Deklarieren von Variablen in einem
Header (sowieso sinnvoll), dort würde Typ und der volle Name angegeben,
der Interpreter substituiert dann einen 2-Byte Code (das wären 65536
verschiedene Variablen), der die Variable beschreibt und beim Befehl
"List" würden diese Variablennamen wieder im Klartext erscheinen.
Übrigens: Wer interesse hat.. ich habe momentan, wie schon oben
erwähnt, zu Testzwecken ein MCS-51 Basic-System am Laufen - vollkommen
Stand-alone, mit einem Terminal bestehend aus einem 40x16 (240x128
Grafik auf T6963-Basis) Display und einer alten PC-Tastatur, die Brücke
bildet ein Mega-8, der sogar eine primitive Edit-Funktion zur Verfügung
stellt. Allerdings ist der Code des Terminals ziemlich Spaghetti, ist
so an zwei- drei Abenden "gewachsen" - müßte ich erst einmal
entwirren...

Autor: AxelR. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

ich habe den MC51Bsic als Steuerung für meine alte 2Meter Mühle am
laufen.
War mal ein Handfunkgerät für 144 bis 146 Mhz. Bei diesem musste man
die Frequenz mit einem Mäuseklavier an der Oberseite einstellen. Das
ganze habe ich nun(damals) in ein Gehäuse gepackt und mit einem 4x16
Display als Anzeige, einige574er als Latch und 5Tasten zur
Menüsteuerung versehen.

Die Idee mit dem Interpreter hat wohl auch Sony-Ericsson aufgegriffen:
Im GSM-Modul GR47 ist auch ein Interpreter drinn, allerdings in C.
Leider ist die IDE nicht der Brüller, grobe Schnitzer werden schon hier
erkannt, kleinerer Fehler werden sang-und klanglos übernommen, beim
Upload gibt es auch noch nicht wirklich Trödel, aber beim Ausführen des
Codes im Modul kommt es dann zu unerklärlichen Fänomenen(wie schreibt
man das?). Auch leidet die Lesbarkeit der Quelle, da die Einrückungen
alle mit als Tabs in den Quelltext eingehen und platz verschwenden
würden, wenn man diese drinnen ließe.
Einen Interpreter zu schreiben, traue ich mir nicht zu. Maximal das
bunte PC-Interface in Delphi -> das kann ich.

Gruß
Axel

Autor: Quark (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@AxelR.
ich glaube, auch mit der neuen Rechtschreibung bleibt es
bei Phänomen.

Grüße

Quark

Autor: Daniel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bei kleinem Programmspeicher (AVR) eignet sich Basic nicht so gut. Wer
einen Interpreter selbst programmieren will, der PC-unabhängig direkt
auf dem Mikrocontroller laufen soll, sollte stattdessen Forth
vorziehen. Diese Sprache ist einfacher zu implementieren und läuft um
ein Vielfaches schneller als Basic, da zuerst in einen Zwischencode
compiliert wird und dieser recht schnell ausgeführt wird. Bei Forth ist
der Interpreter aber nach dem Minimalprinzip ausgeführt, um
Speicherplatz zu sparen. Ausdrücke müssen in Postfix-Schreibweise
notiert werden (siehe alte HP-Taschenrechner).. ansonsten ist es aber
eine vollwertige Hochsprache.
Wer sich mit der Sprache anfreunden kann (viele Informationen im Netz,
meist nur englisch), dem könnte ich Tipps geben, wie man es auf dem AVR
umsetzen kann..

Grüße
Daniel

Autor: Johannes Zinnau (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mhhhh das währe auch ganz interesant.

Autor: Hagen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Naja, es hindert ja keinen daran auch BASIC Sourcen vor dem ausführen in
einen Zwischencode -> PCode, umzuwandeln.

Nur benötigte man dann AVRs die auch ein gutes Stück an SRAM enthalten,
bzw. externen SRAM haben.

Am cleversten wäre es aber immer noch auf dem PC den Source in PCode
umzuwandeln und im AVR selber nur den PCode Interpreter zu bauen. Dies
ist sogar die üblichste Vorgehensweise, zB. gibt es eine solchen PASCAL
Interpreter für AVR's oder die BasicCards, SmartCards der Firma
ZeitControl arbeiten so. Übrigens einige SmartCards der BasicCards
laufen auf AVR SmartCard Prozessoren.


Gruß Hagen

Autor: Daniel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Hagen:
stimmt, so wird es üblicherweise gemacht.. wenn der Compiler auf dem PC
läuft, kann einiges an Intelligenz reingesteckt werden und ordentlich
optimiert werden. Der Nachteil ist, dass man immer einen PC im
Schlepptau hat und ein Programmierer, der den Compiler bedienen kann.
Dieser Aufwand ist nicht nötig, wenn man nur eine kleine Steuerung
braucht, die sich vielleicht in der Garage befindet. Dann wäre es
schön, wenn die Entwicklungsumgebung (im einfachsten Fall eine
Eingabezeile) sich direkt auf dem Zielrechner (hier Mikrocontroller)
befindet.
Ein Interpreter hat zudem den Vorteil, dass direkt Kommandos ausgeführt
werden können, ohne das ein Compilieren, Übertragen und Neustarten des
Programms nötig ist.
Um externen SRAM kommt man natürlich nicht drum herum.


Daniel

Autor: thkais (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Daniel: Warum in Gottes Namen hält sich das Gerücht, Basic sei langsam,
so lange? Schau Dir mal "PureBasic" für den PC an, da wird Visual C
blaß. Ob ich Basic, C oder Pascal als Interpreter irgendwo
implementiere, ist absolut wurscht, es kommt auf die Effektivität des
Interpreter - Codes an. Daß auf einem 2313 ein vollwertiger Interpreter
nicht laufen wird, ist auch klar, aber es muß nicht unbedingt ein
Speicherriese sein.
Und das sog. "vorcompilieren" hat schon der ZX-80 von Sinclair
gemacht... Nur mal zur Information: Der ZX-81 hatte 1KB RAM.
Eigentlich alle Interpreter auf den damaligen Homecomputern hatten
einen Tokenizer, der die Befehle in einen Byte-Code umgesetzt hat.
Lediglich Ausdrücke waren noch im Klartext. Verzichtet man auf
verschachtelte For-Next und auf Gosub, kommt man sogar ohne einen Stack
aus.  Und wenn wir wieder einen PC zum Kompilieren von Byte-Code
brauchen, dann kann man gleich auf BASCOM umsteigen und erhält nativen
Code.

Autor: Ratber (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Warum in Gottes Namen hält sich das Gerücht, Basic sei langsam,
>so lange?

Na aus dem gleichen Grund warum IBM-HD's "immer" Schei** sind,ATI
immer Mackige Treiber hat,Nvidia immer Schlechte Bilder liefert,AMD
immer Heiß und empfindlich ist,Intel immer viel zu Teuer für die
Leistung ist und Audi's immernoch schneller Rosten als se fahren ;)

Autor: thkais (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
g ja, so isses. Aber das mit dem Rost, das war doch Opel, oder ? ;-)

Autor: Josef (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Muß ich einfach sagen:

Das MCS 51 Basic war und ist genial. Für neuere Projekte würde ich es
aber nicht mehr nehmen. Es gibt bereits sehr gute, verbesserte
Versionen, die im Eprom ablaufen. (zB: bei Ribu.at, MICRO515-Basic / 32
KB EEPROM
).


SG Josef

Autor: Philipp Sªsse (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
[Daniel:]
> Um externen SRAM kommt man natürlich nicht drum herum.

Warum nicht? Wenn Du kein Basic nimmst, sehe ich da keine Probleme.

[thkais:]
> Daß auf einem 2313 ein vollwertiger Interpreter nicht laufen
> wird, ist auch klar

Der könnte gerade die untere Grenze darstellen, wenn man Bedienung über
die UART akzeptiert (Standalone mit LCD und Tastatur würde ich nicht
unter atmega8xxx anfangen, denn dann muß auch ein minimaler Editor mit
rein).

Platz für gewaltige Programme bleibt da wohl nicht, aber sinnvoll wäre
es durchaus, um z.B. die Funktion einer Platine interaktiv zu prüfen,
das Zusammenspiel mit anderen Komponenten zu testen und einfache
Aufgaben zu realisieren.

Voraussetzung wäre wohl ein Minimalsystem plus Aufbaubibliothek, aus
der man sich einfach den Umfang zusammenstellen kann, den man braucht.

Gruß, Philipp.

Autor: Daniel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@thkais:
Es geht darum, ein komplettes Interpreter-System auf dem AVR
unterzubringen. Also wie Philipp schon schreibt: einfacher Editor über
LCD und Tastatur. Was meinst du dann mit PureBasic oder BASCOM, die
sind doch fehl am Platz, oder ?!

@philipp:
Ich hab Bedenken wegen der maximalen Schreibvorgänge des FLASHs. Da ein
Interpreter vom Umprogrammieren lebt, würde ich lieber SRAM verwenden
und einen AVR mit ext. Speicherinterface wie mega8515.

Daniel

Autor: thkais (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Daniel: Bitte richtig lesen. "Purebasic" und "Bascom" fielen in
einem anderen Zusammenhang als Antwort auf einen Beitrag
("Geschwindigkeit von Basic allgemein" und Stichwort "vorcompilieren
auf einem PC").

Man könnte ein Speicherinterface mit 64K Adressraum und parallelem
8-Bit Zugriff mit 10 I/O-Pins aufbauen. Oder, wie schon weiter oben
erwähnt, per I2C oder SPI einen externen Speicher aufbauen - allerdings
auf Kosten der Geschwindigkeit.

Autor: Daniel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@thkais:
Die "Geschwindigkeit von Basic allgemein" hatte ich nicht gemeint,
sondern nur die von Basic-Interpretern auf Mikrocontrollern, die nicht
in Maschinencode compilieren können. Also klassisch aneinander
vorbeigeredet.. :)

Daniel

Autor: thkais (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Könnte man so sagen ;)
Aber weshalb sollte Forth schneller als Basic sein?
Ich habe mir mal den Intel-Basic Interpreter angeschaut, und der ist
hauptsächlich so lahm, weil er nur Floating-Point Operationen kennt
(und die sind BCD-basiert) und weil er die Syntax zur Laufzeit prüft.
Würde man einen Pre-Run (ähnlich wie Qbasic) machen, d.h. den
Syntax-Check vom eigentlichen Programmablauf abtrennen, und dann noch
Integer-Variablen einführen, ließe sich mit Sicherheit etwas machen.
Und den Expression-Interpreter kann man auch vereinfachen, indem man
nur einfache Operationen nach Schema A=B+C zuläßt, d.h. der Anwender
muß die Rechenoperationen in einzelne Pakete aufteilen.
Auch interessant wäre das Vorberechnen der Sprungmarken (für Gosub,
For-Next, Repeat-Until). Die werden z.B. beim MCS-51 Basic erst
berechnet, wenn es soweit ist; Sprich: Der Interpreter wuselt sich bei
Sprungmarken durch alle Zeilen durch, bis er sie findet. Würde man
diese Sprungmarken im PreRun berechnen und als Binärwert (Pointer
direkt zur Zeile) ablegen, würde man im Programmverlauf einiges an Zeit
sparen. Ist also alles eine Frage der Optimierung.
Ob ein Ausgabebefehl dann "print" oder "write" heißt, ist dann
wurscht...

Autor: Daniel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@thkais:
hast schon Recht, man könnte aus Basic einiges herausholen, wenn es
speziell für den AVR optimiert ist. Forth ist halt nur einfacher
aufgebaut als Basic, deshalb hatte ich mich damit versucht, weil das
Leben wohl zu kurz ist, um selbst einen kompletten Basic-Interpreter in
der Freizeit zu entwickeln... :) Forth hat wie Basic zwei Interpreter:
der erste wandelt die Eingaben in einen Zwischencode und der zweite
führt diesen so schnell wie möglich aus. Dieser zweite Interpreter
fällt bei Forth extrem kurz aus (beim AVR beispielsweise 5
Assemblerbefehle bei Hardware-Speicherinterface), da der Zwischencode
im Grunde nur aus vorberechneten Adressen besteht. Das alles basiert
auf einen Stackprozessor, den man mit den AVR nachbildet (AVRs eignen
sich dafür ganz gut, auf einen 8051 ist mehr Aufwand erforderlich)

Daniel

Autor: thkais (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe mir nochmal ein paar Gedanken gemacht und stehe nun vor einem
ziemlichen Problem. Eigentlich hätte ich gerne auf Zeilennummern
verzichtet, aber das wird wohl nicht gehen: Wenn wir von einer
Editierung "vor Ort", also z.B. über eine Terminalverbindung per
RS-232, ausgehen, dann klappt das nicht ohne Zeilennummern -
schließlich soll auch ein "dummes" Terminal, das nur aus Display und
Tastatur besteht, in der Lage sein, damit zu arbeiten. Auch beim
Editieren wird man das Problem haben, daß man garnicht weiß, welche
Zeile genau denn nun gerade editiert wird, weil man eben keinen
Full-Screen Editor implementieren kann.
Eine Alternative wäre die automatische Nummerierung, wobei die Nummern
nur vom Editor erzeugt, aber nicht im Programmcode gespeichert werden -
sozusagen als Hilfsanker.
Die andere Alternative besteht darin, dem Basic-Interpreter ein eigenes
Display zu spendieren, auf dem dann ein Full-Screen Edit möglich ist -
zu aufwendig und zu speziell.
Eigentlich würde mir ja dieser minimal-Zeileneditor aus dem MCS-51
reichen - nur der benötigt definitiv Zeilennummern.
Hat vielleicht einer eine Idee, die ich nicht sehe?

Autor: Philipp Sªsse (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
... und noch ein Problem, daß bei Forth quasi inhärent gelöst ist! (-:

Autor: Hans (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
kleiner einwandt zum thema zeilen nummern und so... bild doch ein vt-100
terminal nach ;) dann kannst über die serielle mit hyperterm drauf
herumbasteln wenn du willst wie auf ner unix-shell mit telnet g
forth müsst ich mir mal anschaun..hab schon einiges drüber gehört...

im prinzip is das eine gute idee...aber warum implementiert man dann
nicht gleich eine java virtual maschine... dann könnte man java laufen
lassen g

wär doch witzig ;) und nebenbei wäre dann das simulator-basteln ein
klax...

sind die virtual-maschine-specs eigentlich frei ?? würd mich
interessieren...

73 de oe6jwf

Autor: thkais (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Philipp: Sorry, von Forth habe ich vor 15 Jahren mal etwas gehört -
aber bevor es so interessant wurde, daß ich mich damit beschäftigt
hätte, war es wieder in der Versenkung verschwunden.
Ich verstehe nicht so ganz, wieso Forth das Problem, einen Source-Text
editieren zu können, lösen soll.
Mir geht es darum, daß man unter Umständen auch nur ein ein- oder
zweizeiliges Display an der Kiste haben könnte. Unter diesen Umständen
ist es ohne eine Zeilennummerierung quasi unmöglich, sich zu
orientieren - denn man weiß ja nie, wo man sich gerade befindet, weil
die Zeilen vor- und nachher nicht sichtbar sind. Einen Interpreter zu
basteln, der ohne Zeilennummern auskommt, ist kein grundsätzliches
Problem. Es ist nur so, daß Zeilennummern den Editor vereinfachen
würden.
Wie kann mir da Forth helfen - schließlich brauche ich auch dort
Anhaltspunkte, in welchem Teil des Source-Codes ich mich befinde.

Java? Sorry, da klinke ich mich genauso aus, wie bei Forth. Weder die
eine noch die andere Sprache beherrsche ich. Ob Java frei ist, weiß ich
nicht so richtig - war da nicht irgendetwas mit Sun?

Autor: thkais (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Hans: VT-100 war ein gutes Stichwort. Ich kannte diesen
Terminal-Standard zwar schon, aber wußte nicht, daß der Befehlsumfang
so groß ist. Damit ließe sich tatsächlich ein Full-Screen Editor
aufbauen.
Ist nur die Frage: Braucht man das?
Ein Full-Screen Editor ist nur sinnvoll mit einem großen Display. Ein
großes Display ist eigentlich nur sinnvoll in Form eines Laptops. Und
wenn ich jedesmal den Laptop anwerfen muß, dann ist der Schritt vom
Interpreter weg zum Compiler auch nicht mehr groß.
Wie schon oben erwähnt: Man muß auch mit einem kleinen Display arbeiten
können. Das größte, das noch einigermaßen bezahlbar ist, ist ein 240x128
= 40 Zeichen auf 16 Zeilen.

Autor: DerMax (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
vt100 kennt zwar recht viele befehle aber die wirklich wichtigen lassen
sich an ein bis zwei händen abzählen und sind sehr einfach zu
implementieren.
Ich denke UART und ein terminalprogramm wär schon das gegebene, man
muss ja kein Laptop nehmen ein PDA würde es da ja auch schon tun
(obwohl ich nicht weiß ob man für die vt100 terminal software bekommt)

Java? Das soll ein Witz sein oder? Ich mag Java, aber ein AVR dürfte
damit wohl etwas überfordert sein. Es ist auf jeden Fall 32bittig und
durch die Objekt orienttiertheit brauch man auf jeden Fall
vviiiiieeeeeeellll RAM, und wenn du mit dem virtual machine code
arbeiten willst brauchst du ja wieder einen Compiler auf dem PC...

Autor: Philipp Sªsse (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@thkais: in Forth schreibt man ja praktisch nur 1-zeiler Prozeduren, die
dann von anderen wieder aufgerufen werden. Es heißt, wer Mehrzeiler
braucht, hat schlecht programmiert. (-:

@Hans: Java VM auf einem AVR? Ist weder realisitisch noch sinnvoll,
denn für interaktives Arbeiten ist Java auch wieder nicht geeignet.

Ich habe ohnehin den Eindruck, daß hier viele unterschiedliche
Zielsetzungen durcheinandergeraten. Der eine will ohne PC entwickeln,
der andere debuggen; einem geht es um die Einfachheit, dem anderen um
die Interaktivität. Wenn man alles unter einen Hut bringen will, wird
der Hut keinem passen ... (-;

Autor: Daniel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@thkais: Zeilennummern wären bei einem kleinen Display sehr hilfreich.
Die Zeilennummern müssten aber schon einen festen Abstand haben
(1,2,3,...) und nicht beliebig wie typischen Basic, wo man noch mal
eine Zeile hinterher dazwischenmogeln kann (10,20,25,30,40). Danach
kann man es sich dann zeilenweise auslisten. Ich sehe auch keinen
Ausweg, ohne Zeilennummerierung auszukommen.
Zeilenorientiert kann ja jedes einfache Terminalprogramm (Enter und
Backspace).

Daniel

Autor: thkais (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Daniel:
So habe ich mir das auch vorgestellt: Keine feste Nummerierung, sondern
eine vom Editor generierte. Scheint die einzig sinnvolle Idee zu sein.
Naja, die Tage werden jetzt kürzer - ich wollte eigentlich schon länger
mal einen einfach gehaltenen Interpreter basteln, so eine Art SPS-Ersatz
um schnell mal irgendwo ein Progrämmchen reinzuhacken. Mal sehen, ob was
draus wird.

Autor: Daniel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
..schon einen Algorithmus ausgetüftelt, um Ausdrücke / Befehle
auszuwerten ??

Daniel

Autor: thkais (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Befehle sind kein Thema, das ist eine einfache Sprungtabelle
Token->Adresse.
Bei Ausdrücken wirds schon interessanter, wenn man Punkt vor Strich,
Klammerregel und sonstige Prioritäten beachten muß. Um das Ganze zu
vereinfachen, umgehe ich dieses Problem zunächst - es wird nur zwei
Argumente geben (wie schon weiter oben erwähnt). Das dürfte der
Übersichtlichkeit und auch der Geschwindigkeit zuträglich sein.
Heißt also: Ein  Ausdruck kann nur die Form
<Ergebnis> := <Argument1> <Operand> <Argument2>
haben - Ausgenommen Funktionen wie z.B. ABS() oder INT().

Das Internet sollte so etwas auch hergeben.
Vor fast 20 Jahren habe ich mal mit einem Schulkollegen innerhalb eines
Referats einen Compiler gebastelt - da war eine entsprechende Auswertung
von Ausdrücken drin, aber frage mich keiner, wie das Ding
funktionierte.
Alles in Allem werde ich aber vor Weihnachten nicht dazu kommen - wenn
überhaupt... wäre (leider) nicht das erste Projekt, das aus Zeitgründen
die Schublade nicht verläßt :(

Autor: Andreas Schwarz (andreas) (Admin) Benutzerseite Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Was ist denn inzwischen aus dem Projekt geworden?

Autor: thkais (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Leider nix - irgendwie hat man immer zu wenig Zeit...

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.