FemtoBasic - zu buggy zum benutzen..?

[petersieg]

Hi. Ich habe mal ein wenig mit Femtobasic rumgespielt..
Selbst einfachste Programme lassen sich nicht laden und das System scheint zu hängen..
(test.bas geht.. aber anscheinend, wenn es etwas länger wird hängt es..?)

So einfache Sachen wie lotto.txt sollten doch laufen.. oder Nim Spiel (23.txt).

Habe dann den Lottozahlen Generator direkt mal eingetippt.. Zuerst (bis d) sah
es gut aus.. dann hat es sich wieder aufgehangen bei Verarbeitung einer Eingabe-
zeile..(Tokenisieren?)..

cat.txt wird einwandfrei geladen (wieder ein ganz kleine Datei..?) und läuft auch,
aber anscheinend wird das Dateiende nicht erkannt..? Auf Nicht-HIVE soll das aber genauso
funktionieren!

So ist das leider nicht zu benutzen! Evtl. hat ja jemand eine Idee..
Ob das jetzt an den Anpassungen für ios/HIVE liegt..?

In basic.zip habe ich die kleinen Basic Programme mal angehangen..

Peter

[Rainer]

Hi Peter,

ich habe damit nur mal ein bischen rumgespielt.
Hab's dann aber gleich wieder sein lassen. Ein Basic ohne Strings und solche Sachen ist eigentlich kaum wirklich brauchbar.
Ich nehme an, es war einfach nur eine einfache Implementation für Roboter-Steuerungen.
Dabei will ich nicht meckern .. ich könnte keinen Basic-Interpreter programmieren.

Da muß jemand (aber bestimmt nicht ich) mal mit der "groben Kelle" drübergehen ... oder gleich was Neues schreiben.

Gruß.
Rainer

[digger]

Wir hatten doch einen Compiler/Sprachen Spezi unter uns .. was das nicht der DJ?

[drohne235]

Bei der Anpassung hab ich diverse Teile auskommentiert, die auf dem Hive keinen Sinn ergeben. So z.B. alle Routinen um Programme oder Daten im EEProm zu speichern. Um ehrlich zu sein war es mehr eine kleine Fingerübung - ich habe da nie mehr als Dreizeiler eingegeben die dann auch liefen und sich speichern ließen. Mir persönlich war der Quelltext einfach zu unübersichtlich, ich konnte mich da nicht wirklich bis in die Tiefe reindenken. Wenn ich ehrlich sein soll bin ich zu dem Schluss gekommen das es für mich persönlich einfacher wäre ein eigenes modulares, übersichtliches und gut kommetiertes Basic zu programmieren als große Änderungen in Femto zu machen und letztlich müsste man ja wenigstens noch diverse ios-Funtkionen einarbeiten um es auf dem Hive richtig schnucklig zu machen.

Wenn also was nicht funktioniert, einfach mal debuggen und ändern. Und wenn jemand rausbekommt wie man ein neues Kommando einfügt (z.B. ein "bye" um den Interpreter sauber zu verlassen) mal hier die Erkentnisse zur Struktur posten - ich hab das nicht hinbekommen.

[Rainer]

Also ich würde da ehrlich gesagt keine Arbeit reinstecken.
Lieber neu programmieren .. modular wie drohne schon sagte. Das ist für eventuelle Compiler die später vll. gemacht werden auch einfacher.
Mit einer reinen Interpretersprache ist der Hive eigentlich unterfordert.
Ein ECHTES HIVE-Basic wäre schon cool. Ob man die Sprache jetzt mag oder nicht ... die meisten fangen damit an zu programmieren. Die Hemmschwelle es mal mit dem HIVE zu probieren würde drastisch fallen.

Gruß.
Rainer

[drohne235]

Ein ECHTES HIVE-Basic wäre schon cool.

Und ich vermute mal (hab da noch keine praktischen Erfahrung) das ein Basic-Compiler der Tokencode für die SPIN-Tokenprozessoren erzeugt nicht wirklich schwierig wäre. Wenn wir es mal schaffen würden genug Informationen über diesen Tokencode zu sammel/finden und dieser in der Wiki ordentlich dokumentiert ist wäre das echt eine Basis für diverse Compiler.

[ringo]

Ein ECHTES HIVE-Basic wäre schon cool.

Und ich vermute mal (hab da noch keine praktischen Erfahrung) das ein Basic-Compiler der Tokencode für die SPIN-Tokenprozessoren erzeugt nicht wirklich schwierig wäre. Wenn wir es mal schaffen würden genug Informationen über diesen Tokencode zu sammel/finden und dieser in der Wiki ordentlich dokumentiert ist wäre das echt eine Basis für diverse Compiler.

Das wäre wirklich eine große Hilfe. Ich hätte schon Lust, so ein Basic und auch andere Compiler zu implementieren. Aber erstmal muss ich noch meinen HIVE zusammenbauen und zum Laufen kriegen In den nächsten Tagen werde ich endlich loslegen. In diesem Zusammenhang besten Dank für das klasse Wiki, das ist eine große Hilfe, weil man sich nicht mehr alle Infos aus dem Forum zusammensuchen muss.

Hilfreich wäre auch eine Prioritätenliste, welche Features das Basic haben sollte.

[petersieg]

@ringo: Prima.

Nun zuerst einmal muß es stabil laufen inkl. save+load.
Zusätzlich zu den Femto Features:
String Variablen + Funktionen (Mid$..)
Variablen Arrays (a[..])
Float Variablen

Bei dem HIVE FemtoBasic werde ich den Verdacht nicht los, das der Programmspeicher ab einem 10 Zeiler irgendwie
durcheinander kommt, bzw. was überschreibt.. könnte also einfach zu finden sein..

Peter

[ringo]

@ringo: Prima.

Nun zuerst einmal muß es stabil laufen inkl. save+load.
Zusätzlich zu den Femto Features:
String Variablen + Funktionen (Mid$..)
Variablen Arrays (a[..])
Float Variablen

Bei dem HIVE FemtoBasic werde ich den Verdacht nicht los, das der Programmspeicher ab einem 10 Zeiler irgendwie
durcheinander kommt, bzw. was überschreibt.. könnte also einfach zu finden sein..

Peter

Ich würde davon Abstand nehmen, das HIVE-Basic auf FemtoBasic aufzusetzen, weil ich die Erfahrung gemacht habe, daß eine Neuimplementierung in dieser Größenordnung schneller ist. Natürlich schaue ich mir die Implementierung von FemtoBasic näher an, um gute Konzepte ggf. zu übernehmen.

Für die Featureliste sollten wir eine spezielle Kategorie im Wiki anlegen. Dort sollte auch die Sammlung der Spin-Tokens rein.

Das HIVE-Basic (ich nenn das hier mal HBASIC) würde ich iterativ entwickeln. Ich muss mich ja erst noch in den Propeller-Assembler und Spin einlernen. Im ersten Schritt würde ich vorschlagen, einen HBASIC->Spin Compiler erstellen, um die Features zu testen bzw. neue zu finden. Im nächsten Schritt wäre ein HBASIC->SpinToken Compiler dran. Im dritten Schritt HBASIC->Assembler bzw. SpinToken->Assembler, der für alle folgenden Sprachen benutzt werden könnte.

Wir sind allerdings nicht auf SpinTokens festgenagelt. Evtl. bietet sich auch ein völlig neuer Bytecode an. Auch Forth wäre ein Kandidat für den Objektcode. Forth würde ich hier nur als Zielsprache sehen (in der man natürlich auch entwickeln kann, wenn man mag). Das würde zum einen die Compiler-Erstellung vereinfachen (HBASIC->Forth wäre leichter zu implementieren als HBASIC-SpinToken bzw. HBASIC->ASM), zum anderen ist Forth exzellent kompakt und auch die Performance dürfte deutlich höher als SpinTokens sein.

Wir müssen uns allerdings etwas einschränken, was die Features betrifft. Der HIVE ist ein Embedded System, d.h. wir müssen uns den Hardware-Gegebenheiten (Speicherlimits etc.) anpassen. Insofern stellt sich z.B. die Frage, ob ein Garbage Collector (GC) für Strings auf dem HIVE überhaupt Sinn macht oder ob es nicht klüger wäre, das Speichermanagement dem Entwickler zu überlassen. Wir könnten einen GC installieren, das würde aber drastisch die Performance drücken, zumal der Stringspeicher nur im shared RAM liegen könnte und alles über den Hub läuft, der bei ungünstigen Zeitpunkten zu einem echten Flaschenhals werden kann.

[laserjones]

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?