HIVE-Project

...von einem Compiler, der auf dem HIVE läuft, so dass Programme auf dem HIVE erstellt/editiert und ausgeführt werden können.

Die Idee war einen Compiler zu bauen, der in seiner eigenen Sprache geschrieben ist. Damit ist der Compiler in der Lage, sich selbst zu übersetzen, also zu reproduzieren.

Recherchen dazu haben mich zu Small-C geführt (http://en.wikipedia.org/wiki/Small-C). Small-C ist ein Subset von C, aber ausreichend funktionsstark, so dass der Compiler sich selbst reproduzieren kann. Ein Compiler für DOS ist verfügbar, welcher ASM-Code für 8086 produziert. Dieser ASM Code muss dann von einem Assembler und Linker zu einem EXE File gebunden werden. Dies funktioniert für DOS soweit prima.

Der Compiler Code lässt sich mit ein paar Anpassungen auch mit dem GCC übersetzen. Damit habe ich nun einen Small-C Cross-Compiler (Linux als Host, DOS als Target). Windows wäre auch möglich.

Die Idee war nun, den Compiler (Backend) soweit anzupassen, dass er PASM-Code für den Propeller generiert.

Damit könnte im ersten Schritt Code für den Propeller (noch auf dem PC) generiert werden. In Verbindung mit einem Editor, Assembler und Linker (in Small-C programmiert und in TriOS integriert) wäre in einem zweiten Schritt der Übergang vom PC auf den HIVE möglich.

Ich bin mit meinen HIVE Projekt noch nicht sehr weit, die nackte Platine liegt noch hier , daher habe ich keine Ahnung, wie TriOS funktioniert und was bei der Laufzeitumgebung für Small-C beachtet werden müsste. Für Anregungen und Kritik aller Art bin ich daher offen.

Ich habe gesehen, dass es schon mehrere Threads hier im Forum zu anderen Sprachen und Compilern für den HIVE gegeben hat. Es scheinen aber alle irgendwie eingeschlafen zu sein (oder täusche ich mich?). Gibt es technische Gründe dafür? Oder besteht kein wirklicher Bedarf?

Gruß Joe

Hi,
klingt super.

Hast du auch mal den TCC angeschaut?
http://bellard.org/tcc/

Gruß Höp

Hallo,

den TCC habe ich mir nicht wirklich angesehen. Ich hatte nur mal einen Blick auf den Umfang der Sourcen geworfen und dann wieder verworfen.
TCC: ca. 800 KB
Small-C: ca. 100 KB

Der TCC ist natürlich ein echter C-Compiler, daher sind die beiden nicht wirklich vergleichbar.
Hast du Erfahrung mit dem TCC?

Gruß Joe

Ein toller Traum! Ein paar Ideen dazu, aber nicht auslachen, bin nicht so der Softwareprofi:

Ich bin mit meinen HIVE Projekt noch nicht sehr weit, die nackte Platine liegt noch hier , daher habe ich keine Ahnung, wie TriOS funktioniert und was bei der Laufzeitumgebung für Small-C beachtet werden müsste. Für Anregungen und Kritik aller Art bin ich daher offen.

Die Struktur der Propellerchips ist da etwas eigen. Direkten Maschinencode kann eine COG nur im winzigen RAM in der COG ausführen. Aus diesem Grund geht Spin den Weg, dass der Compiler einen Zwischencode erzeugt, welcher dann von von einem kleinen Spininerpreter ausgeführt wird, der wiederum als Maschinencode in die entsprechende Cog geladen wird. Keine schlechte Variante, wenn man sich anschaut wie kompakt dieser Code ist.

Catalina-C geht da auf dem Prop einen anderen Weg, indem ein LMM (Large Memory Model) verwendet wird.

Catalina: http://propeller.wikispaces.com/Program ... -+Catalina
LMM http://propeller.wikispaces.com/Large+Memory+Model

Allerdings ist das auch keine wirklich ressourcenschonende Variante, da die COG's ja immerhin einen 32Bit Befehlscode haben - damit wird dann aus 32 KB Hubram mal eben 8 K Befehlscodes!

Vielleicht wäre eine interessante Variante die Verwendung der Zog für den Prop, einer Implementation der Zylin CPU. Der Befehlscode im Hubram hat Bytegröße und wenn ich mich nicht irre, war auch schon eine Möglichkeit enthalten, einen externen RAM zu verwenden.

ZOG: http://forums.parallax.com/showthread.p ... ight=zylin
Zylin CPU: http://opensource.zylin.com/zpudocs.html

Wenn man also den Small-C Compiler so gestaltet, dass er Maschinencode für dei Zylin CPU ausspuckt, wäre man schon ein Stück weiter. Vielleicht macht es sogar Sinn, die Buskommunikation zu den Slaves und dem externen RAM allgemein in eine zweite Cog neben der Zylin CPU auszulagern. Das wäre dann so etwas wie eine MMU, welche vielleicht auch gleich das Speichermanagment für mehrere Zylin-CPU's realisieren könnte.

An LMM hatte ich auch gedacht. Allerdings hast du recht, die 32 KByte werden auch nicht lange reichen. Deshalb dachte ich auch schon daran (jetzt bitte mich nicht auslachen), den externen Speicher des HIVEs quasi segmentweise im MainRAM "einzublenden" und so eine Cache-Lösung (oder MMU, wie du vorschlägst) zu realisieren. Dazu müsste ein weiterer COG "geopfert" werden, welcher im Hintergrund den "Cache" füllt.

Da die Codeausführung im LMM Betrieb nicht die Schnellste ist (ein Maschinenbefehl alle 16 bis 32 Cycles), sollte ein 2. COG doch in der Lage sein, quasi gleichzeitig im Hintergrund für Nachschub zu sorgen?

Geht dies mit der HIVE Speicheranbindung?

Zur Zylin CPU:
"The ZPU is a zero operand, or stack based CPU. The opcodes have a fixed width of 8 bits."

8-Bit Code klingt erst einmal toll. Wenn das Programm aber größer wird (>64 KByte), werden auch hier Long-Adressen für Daten und Code-Adressierung notwendig (oder?). Der Unterschied in der Codedichte zu 32-Bit Opcode ist dann lange kein Faktor vier mehr.
Hinzu kommt, dass eine 2-Operanden CPU wie der COG in der Regel weniger Befehle benötigt, als eine reine Stack-CPU. Also auch daher sollte der Unterschied zwischen den Beiden nicht so groß sein.

Außerdem finde ich, eine Stack-CPU kommt dem Propeller nicht gerade entgegen, da er alles andere als eine Stack-Maschine ist. Daher kann ich mir kaum vorstellen, dass die Performance hier berauschend ist. (Schnell soll die Lösung mit Small-C natürlich schon sein , irgendwo zwischen Spin und ASM)

Die Idee mit dem Small-C Compiler war, den COG als Register-Maschine zu nutzen und lokale Variablen im COG-RAM (quasi in Registern) abzulegen. Globale Variablen und ein Stack zur Sicherung lokaler Variablen und Rücksprungadressen soll ins Main-RAM.

Es wären aber auch andere Speichermodelle vorstellbar, je nach Anwendungsfall.
Am Anfang wird die Lösung sicher noch sehr einfach ausfallen (z. B. ohne Cache).

Auch Ich bin mit meinen HIVE Projekt noch nicht sehr weit, nur die Stromversorgung ist Fertig (warte noch auf einige Bauteile im Versand). Also am moment etwas Zeit um über Software nach zu denken.

Ich glaub das mit Small-C wird funktionieren, aber Small-C Ausgabe ist assembler, nicht? Dan benötigt man noch eine PASM assembler dazu. Um grossere Programmen ablaufen zu können ist LMM oder XMM nötig. Dass alles zusammen komt sich dann na an Catalina Compiler dran.

Vielleicht is es besser um eine spezialisierter CPU bzw. VM zu benutzen. Wir sind da zwischen Scylla und Charibdis: die limitierte XMM Speicher Bandbreite spricht für viele kompakte, kraftige Instruktionen; ein CPU in 500 PASM Wörter spricht für wenige, Einfach zu dekodieren Instruktionen.

Ich denke die Spin VM oder die ZPU sind gute Modelle um an zu fangen. Zwei COGs, wobei eine die CPU ist und die andere die MMU macht es möglich um eine zwei Stufen 'pipeline' zu machen und Programme etwas sneller ablaufen zu lassen. ZPU/ZOG has zwar 8-bit Instruktionen, aber ist eine 32-bit Architektur optimiert für einfache implementation und C programme. Also, nach portierung von Small-C nach ZPU (stat PASM) und mit eine ZPU assembler bist du sehr na an deine Hive autarken C Umgebung dran.

Selbst bin Ich interessiert um eine PDP11 implementation zu machen, und alte Unix (version 6 und 7) zu benutzen. Diese programme sind auch sehr slank nach heutige Begriff:
- Unix kernel (v6): 26KB
- assembler: 11KB
- C: 44KB
- shell: 6KB
usw.
Meine Wahl is getrieben von interesse am PDP11 und TI990. Für neu Entwicklung werde Ich wahrscheinlich ZPU oder etwas gleichendes (ZPU optimiert für Ablauf auf COG[s]) benützen.

Ich hoffe dies war einfach zu verstehen: Deutsch ist nicht meine beste Sprache.

Paul

PS:
- TCC ist nicht 800KB, sonst 100KB
- Hast du auch dies gesehen (ganz kleiner Anfang von TCC):
http://bellard.org/otcc/

Hallo Paul

Danke für dein Feedback, dein Deutsch ist doch sehr gut.

Bei den 800KB für TCC meinte ich Source Code Größe (inkl. H-Files).
Kompakter (=wenig) Source Code wäre ein Argument für den OTCC. Ich bin mir aber nicht sicher, ob der Code leicht zu pflegen/erweitern ist.

Nachdem nun auch du auf den ZPU hingewiesen hast, werde ich mir die Implementierung mal genauer ansehen...

Hast du dich schon auf einen Compiler für dein Projekt festgelegt?

Gruß Joe

Nein. Am Anfang wird das wohl der Unix v6 C-compiler sein (also ein altes C Dialekt, alter als "K&R" das erst in Unix v7 dabei war).

Andere Möglichkeiten sind:
- pcc (portable c compiler)
- ack (amsterdam compiler kit)
- tcc (tiny cc)
oder etwas neues: ein einfaches C compiler ist etwa 10 Tausand Linien.

Grusse,

Paul

paulruiz hat geschrieben:Ich glaub das mit Small-C wird funktionieren, aber Small-C Ausgabe ist assembler, nicht? Dan benötigt man noch eine PASM assembler dazu.

nicht unbedingt. kommt dadrauf an was damit gemeint ist. Assembler ist die Sprache des CPU, also kann das durchaus das binary sein. Sprich ein Assembler liefert auch nur Assembler.

Wenn ich das so lese, denke ich auch das der erzeugte Code ein virtueller code sein könnte, der von 1-3 Cogs dann schnell umgesetzt werden kann. So ähnlich wie das Apple2 konzept (kompletter apple2 im Propeller) das mir im Kopf rumspuckt. Oder anders ausgedrückt, wie die P-Machine. Das hätte den Vorteil das der ausführende P-Code überall liegen könnte.

Ich glaub das mit Small-C wird funktionieren, aber Small-C Ausgabe ist assembler, nicht? Dan benötigt man noch eine PASM assembler dazu.

Ja richtig. Ich dachte schon an PASM Code. Dies hätte den Vorteil, dass ich erst einmal den Code auf dem PC übersetzen kann. Mehrere PASM Files werden dann zu einem PASM File "gelinkt" und dann über BST oder ähnliches übersetzt und auf den Propeller geladen.

Dies ist aber eher als Migrationspfad zu sehen. In Zukunft soll Assember, Linker und auch sowas wie ein Make mit auf dem Propeller laufen.

Der Vorteil der getrennten Tools und damit der einzelnen Schritte ist der RAM-Speicherverbrauch für den Übersetzungsvorgang. Beim Small-C Compiler liegt dieser (Code + Daten) deutlich unter 64 KByte. Ob dies auf dem HIVe ein Vorteil ist, bin ich mir nicht sicher. Die 32 KByte Grenze wird auf alle Fälle gesprengt und externes RAM wäre ja ausreichend da. Die Frage ist hier nur, wie das externe RAM effektiv genutzt werden kann.

Man könnte mit dem Compiler aber auch direkt Binär-Code generieren. Dazu müssten dann alle notwendigen C-Files "includiert" werden, so dass alles auf einmal übersetzt und gebunden werden kann.

Gruß Joe