Gibt es eine standard stack machine architektur, für die es compiler gibt und die sich leicht auf einen Mikrocontroller implementieren lässt? Forth ist ja auch eine stack machine, ist aber zu komplex glaube ich. Vor allem gefällt mir die sprache an sich nicht :) Am besten wäre ein C ähnlicher compiler der in einen einfachen code kompiliert und eine virtuelle maschine die ich auf dem controller in ASM implementieren kann (also keine riesigen Klassen/Funktionen/etc wie bei Java). Ich könnte auch einen compiler für eine richtige CPU nehmen und die emulieren, das müsste dann aber eine extrem einfache CPU sein. Hat da jemand eine Idee?
Ich hatte auf dem AIM-65 (6502-Prozessor) damals (1979/80) auch ein Forth, das hatte 4 kByte. Eigentlich fand ich die umgekehrt polnische Notation von meinem HP25 ganz praktisch und leicht verständlich, aber mit Forth habe ich auch nichts anfangen können.
Forth ist die wohl einfachste Stackmaschine, mit der man arbeiten kann (man muß ja nicht den ganzen ANSI-Standard implementieren). Da ist nichts komplex, höchstens ungewohnt. Was Du möchtest, ist dagegen extrem komplex: C wurde für "normale Registerarchitekturen" geschrieben, aus C-artigem Code Stackmaschinencode zu compilieren, ist ein gewaltiger Aufwand, viel schwieriger als einen normalen C-Compiler zu schreiben. Wer würde sich diesen Aufwand antun für die paar Stackprozessoren, die es gibt? Und welchen Sinn hätte es, mit großem Aufwand aus C Stackcode zu generieren, um diesen dann wieder mit Aufwand auf einem gewöhnlichen Controller in einer emulierten Stackmaschine laufen zu lassen? Eher könntest Du es mit Lisp versuchen, das ist ja ein bißchen wie "Forth rückwärts" von der Syntax. Aber das wird Dir dann ja wohl auch nicht gefallen. Ein Forth-Interpreter/Compiler samt Stackmaschine braucht dagegen nur ein paar hundert Byte und wird dann in sich selbst weitergeschrieben. So einfach, so elegant, so schön. Saß neulich noch in einem Seminar über Embedded-Software-Tests und dachte die meiste Zeit: "wie einfach ist das doch dagegen mit Forth!". Man muß sich einfach nur einmal darauf einlassen, daß Sprachen nicht prozedural (oder objektorientiert) sein müssen, daß Variablen, Operatoren und Programme eigentlich alles dasselbe sind und daß wir nur wieder lernen müssen, Programme so zu schreiben, wie wir denken statt so, wie man es uns antrainiert hat. Aber gegen die Macht der Gewohnheit kommt man mit Argumenten ja sowieso nicht an ... )-: Nichts für ungut. Also bleibt für Dich wohl nur so eine Minimal-Java-Maschine. Google hilft Dir weiter.
@db1ug: Waren 2 ROMs, also 8KB. @Lupin: Stack-Maschinen in Hardware sind schwer aus der Mode gekommen, ausgenommen zur Unterstützung von Java Bytecodes. Sind zwar im Prinzip sehr einfach zu implementieren, aber mit heutiger Technik viel zu ineffizient.
Man könnte es vielleicht so sagen: Die Java Fritzen wollten Forth verwenden , durften das aber nicht sagen :))))).... Es gibt kaum etwas einfacheres als Forth. Gruß Thomas
Hallo Lupin, da gab es vor vielen vielen Jahren, in der Anfangszeit von Pascal so um 1976, den P4-Pascal-Compiler, der einen P-Code für eine virtuelle Maschine erzeugt hat. Es handelt sich um eine 16bittige Stack-Maschine die sich meinererachtens gut auf einem uController interpretieren lassen müßte. Du könntest auch aus dem P-Code direkt den Maschinencode deines uC erzeugen. Ich habe das mal für den 68000 gemacht. Den Source für den Compiler und den Interpreter der P-Codes, selbst in Pascal geschrieben, findest Du hier, auch die Beschreibung der P-Code Maschine: http://homepages.cwi.nl/~steven/pascal/ Mit "P4 Pascal" läßt sich manches ergooglen. Dann gab es sogar "Concurrent Pascal", das Nebenläufigkeit ermöglichte und auf einem erweiterten P-Code aufsetzt. Gruss Hans-Christian
@A.K. stimmt, der Assembler hatte 4k , Basic und Forth je 8, die Eproms mit 4 k kosteten über 100 DM. Und die ROMs gingen gern mal kaputt
Das ROM des Jupiter Ace, ein Z80-"home computer" aus den frühen 80ern, der als einziger von Hause aus mit Forth arbeitete, war auch 8 kByte groß. Mittlerweile existieren Schaltpläne und auch kommentierte Assemblerlistings des ROMs dieses "Schätzchens". Genügend Masochismus vorausgesetzt, lässt sich damit ja vielleicht was anfangen. @Hans-Christian: Hat dieses Pascal irgendeine Verwandtschaft zum UCSD-Pascal? Mit dem musste ich mir mal auf einem Apple II die Finger beim Diskettenwechseln brechen ... Wenn ich mich recht erinnere, verwendete auch dieses eine virtuelle P-Maschine.
Klassische Stack Maschinen waren die Transputer von Inmos. Dazu gab es C-Compiler und OCCAM. Von OCCAM gibt es auch noch freie Implementierungen. ggl mal danach.
Nicht ganz so klassisch - ein Stack mit 3 Speicherplätzen war doch arg wenig. Und die Transputer waren dermassen strikt auf Occam optimiert, dass Befehle und Funktionalitäten, die für C wichtig waren, für Occam aber nicht, komplett fehlten und C-Compiler dementsprechend ineffezient waren.
@Rufus Ja, das UCSD-Pascal auf dem AppleII basiert auf dem P-Code-Pascal. Wenn der P-Code Interpreter auf dem 6502 läuft, sollte auch jeder moderne uC (mit ausreichend Speicher) genügen.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.