FemtoBasic - zu buggy zum benutzen..?

[petersieg]

Doch, das hatte ich bisher auch so gesehen. Einfache ASCII Dateien für Programmdateien.. Und einfacher Interpreter..

Aber ansonsten nehme ich auch gerne anderes

Von FemtoBasic gibt es inzwischen mehrere Spezialvarianten z.B zum Steuern von Geräten mit halt spezifischen Befehlen..
und auch ein Grafikerweiterung..

Ich denke, das Femtobasic woanders schon stabil läuft! Irgendwo/was ist bei der Umstellung auf den HIVE schief gegangen..
und es kann was mit der Programmspeicherverwaltung zu tun haben, das sich halt erst über den 3-5 Zeilern auswirkt..

Peter

[ringo]

Im ersten Schritt würde ich vorschlagen, einen HBASIC->Spin Compiler erstellen

Ist der Vorteil von BASIC nicht gerade, dass man einen Interpreter zur sofortigen Ausführung hat und keinen Compiler benötigt? Natürlich wäre ein Compiler ebenfalls gut , v. a. als Grundlage für die weiteren von dir aufgeführten Sachen, aber sollte nicht der Interpreter der erste Schritt sein?

Ein Interpreter und Compiler sind zwei völlig verschiedene Schuhe und müssten eigentlich separat implementiert werden. Man könnte allerdings beides in einem Rutsch erledigen durch einen Basic->Forth Compiler. D.h. wenn man die Eingabe direkt nach Forth übersetzt, hätte man einen Compiler, der sich nach außen wie ein Interpreter verhält. Genau das ist eines der Killerfeatures von Forth, was es für Embedded Systems beliebt macht. Forth-Anweisungen werden bei der Eingabe übersetzt und dann der Bytecode interpretiert.

Man müsste praktisch "nur" einen Basic->Forth Source-to-Source Compiler vorschalten. Damit meine ich: man gibt eine Basic-Zeile ein und sie wird intern (quasi unbemerkt) nach Forth übersetzt und dann der Bytecode direkt ausgeführt. Dann hätte man dasselbe Feeling wie bei einem gewöhnlichen Basic-Interpreter, wobei man dann nichts mehr compilieren muß, weil alles schon compiliert ist.

[Janaha]

Über einen Compiler der speziel auf die belange des Hive angepasst ist grüble ich auch schon seit einiger Zeit nach. Ich finde so ein Compiler sollte auch in der Lage sein, Code für Belatrix und Administra zu generieren. Dazu müsste er natürlich die Architektur genauer kennen. Da die beiden ja z.B. keine direkte Anbindung an den "Hauptspeicher" haben. Ich grüble auch schon die ganze Zeit darüber nach, wie man das Cog-Ram und das Hub-Ram sozusagen wie den Level 1 / Level 2 Chace bei StandardPC's am geschicktesten einbindet. Mein Compiler soll am Ende gar kein Spin-Code mehr erzeugen, sondern direkt Assemblerblöcke. Und mein Ziel wäre es auch, das diese Blöcke wenn sie im Cog-Ram landen möglichst nicht immer nur eine Funktion beinhalten sondern auch ruhig mehere, wenn das Cog-Ram dafür ausreicht. Am meisten Kopfzerbrechen bereitet mir immer noch das Problem, das eine einzelne Routine durchaus so geschrieben werden kann, das sie den Cog- Internen speicher übersteigt. Ich möchte aber ereichen, das das den Programmierer am Ende nicht interessieren muss. Er sollte nach möglichkeit so schreiben können als hätte er allen Speicher der Welt. Die eigentliche Verwaltungs sollte nach möglichkeit dann im Hintergrund laufen. Und was das ganze natürlich noch spannender macht ist, das wir durchaus sowas wie Threads brauchen werden, es sein den wir möchten unsere Programme nicht aus mehr als einen Cog verteilen. Oh je, das wird noch was werden. Einen einfachen Basic zu Assembler Compiler kann ich euch recht schnell zusammenfrikeln, aber was wirklich allgemein brauchbares, das wird wohl etwas dauern. Bin mal gespannt, was ihr hier so für den Hive entwickeln werdet.

Ach noch ein Tip. Wenn ihr daran geht das Pferd neu zu bauen. Macht den Compiler / Interpreter doch mehrstufig. Will heissen, wenn ihr nicht gleich Basic zu Binary-File baut, sondern erstmal nur Basic zu Assemblerquelltext. Dann braucht ihr den eigentlichen Codegenerator spähter nur einmal schreiben. Nähmlich Assembler- Quelltext zu Binary. Dann kann man darauf aufbauend jederzeit problemlos mehere Sprachen aufsetzen und müsste sich nicht jedes mal mit dem Part der Binary generierung rumschlagen. Auch den Linker braucht man dann nur einmal machen. Nicht anders haben das die alten DOS-Pascal-Compiler gemacht. Und ganz so nebenbei würde theoretisch auch noch alles was man für "Inline-Assembler-Blöcke" braucht mit abfallen. Die Blöcke braucht man dann spähter nur noch 1:1 in den Assemblerquelltext übernehmen.

Grüße
Janaha

p.s. Ich würde der geschwindigkeit halber auch wohl einen Compiler bevorzugen. Ist meines erachtens nach auch einfacher zu schreiben als ein Interpreter. Und schonmal sorry für das Highjacken des Basic-Interpreter-Threads.

[ringo]

Über einen Compiler der speziel auf die belange des Hive angepasst ist grüble ich auch schon seit einiger Zeit nach. Ich finde so ein Compiler sollte auch in der Lage sein, Code für Belatrix und Administra zu generieren. Dazu müsste er natürlich die Architektur genauer kennen. Da die beiden ja z.B. keine direkte Anbindung an den "Hauptspeicher" haben. Ich grüble auch schon die ganze Zeit darüber nach, wie man das Cog-Ram und das Hub-Ram sozusagen wie den Level 1 / Level 2 Chace bei StandardPC's am geschicktesten einbindet. Mein Compiler soll am Ende gar kein Spin-Code mehr erzeugen, sondern direkt Assemblerblöcke. Und mein Ziel wäre es auch, das diese Blöcke wenn sie im Cog-Ram landen möglichst nicht immer nur eine Funktion beinhalten sondern auch ruhig mehere, wenn das Cog-Ram dafür ausreicht. Am meisten Kopfzerbrechen bereitet mir immer noch das Problem, das eine einzelne Routine durchaus so geschrieben werden kann, das sie den Cog- Internen speicher übersteigt. Ich möchte aber ereichen, das das den Programmierer am Ende nicht interessieren muss. Er sollte nach möglichkeit so schreiben können als hätte er allen Speicher der Welt. Die eigentliche Verwaltungs sollte nach möglichkeit dann im Hintergrund laufen. Und was das ganze natürlich noch spannender macht ist, das wir durchaus sowas wie Threads brauchen werden, es sein den wir möchten unsere Programme nicht aus mehr als einen Cog verteilen. Oh je, das wird noch was werden. Einen einfachen Basic zu Assembler Compiler kann ich euch recht schnell zusammenfrikeln, aber was wirklich allgemein brauchbares, das wird wohl etwas dauern. Bin mal gespannt, was ihr hier so für den Hive entwickeln werdet.

p.s. Ich würde der geschwindigkeit halber auch wohl einen Compiler bevorzugen. Ist meines erachtens nach auch einfacher zu schreiben als ein Interpreter. Und schonmal sorry für das Highjacken des Basic-Interpreter-Threads.

Die ganze Sache läuft IMHO tatsächlich auf einen Basic->Forth Compiler hinaus, wie ich schon weiter oben erwähnt habe. Auch deine Cache-Lösung könnte sich damit elegant lösen lassen, indem man dafür geeignete Forth-Funktionen implementiert. Nennen wir z.B. die Assign-Funktion

Code: Alles auswählen

set!

Eine Basic-Anweisung der Form

Code: Alles auswählen

LET X=A+B*C

würde nach

Code: Alles auswählen

A @ B @ C @ * + X set!

übersetzt werden (wobei @ den Inhalt der Adresse des obersten Stackelements holt). Der Implementierer bräuchte sich über das Caching keine Gedanken machen, wenn sich die set!-Funktion selbst vollautomatisch um die notwendigen Maßnahmen kümmert. In gleicher Weise könnte auch die Ausführung einer Funktion auf einen beliebig freien COG übertragen werden. Das wäre alles Sache des zugrundeliegenden Forth-Systems. Die Sprachen, die darauf aufsetzen, wären davon entlastet.

Was ich mir wünsche ist, daß alle freien COGs und alle Propeller transparent gesehen werden, d.h. es muß völlig egal sein, welchen COG man für welche Zwecke benutzt, abgesehen von den Root-Propellern Administra etc., die für das Betriebssystem reserviert sind. Das ist aber noch alles Zukunftsmusik. Ich denke da schon an eine zukünftige skalierbare "Lego"-Version des HIVE Aber trotzdem sollte man diese Möglichkeit schon mal im Auge behalten.

Auch die Auswahl der System-COGs könnte man leicht in Forth realisieren. In Basic könnte das z.B. so aussehen:

Code: Alles auswählen

with Bellatrix do
   ...

Dann würden sich alle Anweisungen in diesem Block auf Bellatrix beziehen. In Forth müsste dazu einfach nur ein Flag geschaltet werden;

Code: Alles auswählen

Bellatrix ... AnyCog

Der Befehl AnyCog schaltet den Bellatrix-Modus ab und kehrt zum transparenten Modus zurück.

[Janaha]

Was ich mir wünsche ist, daß alle freien COGs und alle Propeller transparent gesehen werden, d.h. es muß völlig egal sein, welchen COG man für welche Zwecke benutzt, abgesehen von den Root-Propellern Administra etc., die für das Betriebssystem reserviert sind. Das ist aber noch alles Zukunftsmusik. Ich denke da schon an eine zukünftige skalierbare "Lego"-Version des HIVE Aber trotzdem sollte man diese Möglichkeit schon mal im Auge behalten.

Halloe.

So ganz egal ist es übrigens nicht, welche COG's verwendet werden. Naja zumindest bei den Grafiktreibern. Da besteht durchaus der bedarf, das die COG's mit einzelnen Funktionsblöcken zur Grafikerzeugung bestückt werden müssen. Wobei dann die COG's die berechneten Daten dann von COG zu Cog weiter reichen und der letzte in der Kette gibt dann das fertige Pixel aus. Also müsste man im Prinzip einmal auch noch sagen können das man für einen Block speziel einen ganz bestimmten Cog braucht oder aber wenns nicht drauf ankommt sozusagen ein "COG-egal" mitgibt. Bzw. das man sozusagen "COG-Ketten" Bilden kann, wo dann garantiert wird, das gewisse Funktionsblöcke sozusagen garantiert auf eine Kette von COG's verteilt werden. Was dann zur folge hat, das das ganze natürlich auch schiefgehen kann, wenn die COG's belegt sind und man dann auch ein entsprechendes Fehlerhandling braucht. usw. usw. urgs da liegt noch viel arbeit drinn.

Naja da spielt natürlich auch meine Vision mit rein, das sich ein Hive-Os spähter komplett selbst auf einem Hive übersetzen können sollte.

Grüße
Janaha

[ringo]

So ganz egal ist es übrigens nicht, welche COG's verwendet werden. Naja zumindest bei den Grafiktreibern. Da besteht durchaus der bedarf, das die COG's mit einzelnen Funktionsblöcken zur Grafikerzeugung bestückt werden müssen. Wobei dann die COG's die berechneten Daten dann von COG zu Cog weiter reichen und der letzte in der Kette gibt dann das fertige Pixel aus. Also müsste man im Prinzip einmal auch noch sagen können das man für einen Block speziel einen ganz bestimmten Cog braucht oder aber wenns nicht drauf ankommt sozusagen ein "COG-egal" mitgibt. Bzw. das man sozusagen "COG-Ketten" Bilden kann, wo dann garantiert wird, das gewisse Funktionsblöcke sozusagen garantiert auf eine Kette von COG's verteilt werden. Was dann zur folge hat, das das ganze natürlich auch schiefgehen kann, wenn die COG's belegt sind und man dann auch ein entsprechendes Fehlerhandling braucht. usw. usw. urgs da liegt noch viel arbeit drinn.

Naja da spielt natürlich auch meine Vision mit rein, das sich ein Hive-Os spähter komplett selbst auf einem Hive übersetzen können sollte.

Auch darin sehe ich kein grundsätzliches Problem. Dafür definieren wir weitere Forth-Funktionen in Assembler, die die Bellatrix-Cogs einzeln auswählen. In Basic dann

Code: Alles auswählen

with Bellatrix(i) do ...