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
FemtoBasic - zu buggy zum benutzen..?
Re: FemtoBasic - zu buggy zum benutzen..?
Zuletzt geändert von petersieg am Fr 7. Aug 2009, 11:59, insgesamt 1-mal geändert.
Re: FemtoBasic - zu buggy zum benutzen..?
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.laserjones hat geschrieben: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?Im ersten Schritt würde ich vorschlagen, einen HBASIC->Spin Compiler erstellen
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.
Zuletzt geändert von ringo am Fr 7. Aug 2009, 12:07, insgesamt 1-mal geändert.
Re: FemtoBasic - zu buggy zum benutzen..?
Ü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.
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.
Re: FemtoBasic - zu buggy zum benutzen..?
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-FunktionJanaha hat geschrieben:Ü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.
Code: Alles auswählen
set!
Code: Alles auswählen
LET X=A+B*C
Code: Alles auswählen
A @ B @ C @ * + X set!
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
...
Code: Alles auswählen
Bellatrix ... AnyCog
Re: FemtoBasic - zu buggy zum benutzen..?
Halloe.ringo hat geschrieben: 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.
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
Re: FemtoBasic - zu buggy zum benutzen..?
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 dannJanaha hat geschrieben: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.
Code: Alles auswählen
with Bellatrix(i) do ...