HIVE-Project

Blöde Frage, ich weiß

Aber was genau ist m? Ein Forthsystem als Ersatz für TriOS?

Was ist der Unterschied zum jetzt bereits integrierten Forth? Basiert es auf PropForth?

Beste Grüße,

oxo

m ist ein Forth, welches ich gerade selbst programmiere. Über die Integration in TriOS bin ich mir noch nicht ganz klar, könnte sein, dass es vielleicht mal PropForth dort ersetzt. Falls nicht, wird es statt TriOS das Betriebssystem mental mit m als Kern geben.

Unterschied PropForth zu m: PropForth ist primär für einen einzelnen Propellerchip geschrieben und dafür auch toll. Folgende Dinge befriedigen mich aber auf dem Hive dabei nicht:

1. Es ist zu groß.
2. Es bietet zwar Multitasking auf Anwenderebene (ich kann mit mehreren orthterminals arbeiten), aber das hat seinen Preis in einer entsprechenden Komplexität.
3. Da es für einen Chip geschieben ist, nutzt es die Möglichkeiten des Hives nur wenig aus.
4. PropForth ist zum Teil etwas langsam.

Das soll jetzt keine Meckerei sein: Ich kann nicht erwarten, dass Sal Sanci nur für den Hive eine ganz spezielle Version schreibt. Deshalb habe ich einfach die Sache selbst in die Hand genommen und ein eigenes spezielles Hive-Forth angefangen.

Ziel ist es, ein Forthgrundsystem mit deutlich unter 5 KB Speicherverbrauch in Regnatix zu schreiben. Ich bin jetzt glaube beim aktuellen Arbeitsstand bei knapp über 2 KB. Dabei verstehe ich unter einem Grundsystem ein System, mit welchem man wirklich autark (Editor, Quelltextverwaltung, Dateiverwaltung) auf dem Hive arbeiten kann. Zudem ist ist m etwas schneller als Spin und deutlich schneller als PropForth. Multitasking auf Anwenderebene werde ich nicht integrieren, aber es können natürlich mehrere COG's parallel Forthcode abarbeiten. Dafür kann m schon mit nativen Worten mit den anderen Chips und dem eRAM kommunizieren, was bei PropForth ja Metadefinitionen waren.

Da ich im Gegensatz zu einem klassischen Forth verschiedene Dinge in die anderen Chips ausgelagert habe, ist m halt ein wenig anders. So läuft der Parser und Screeneditor in Bellatrix und liefert an m vorgeparste Token, bei der Eingabe werden diese schon mit Farben quasi vom Programmierer in ihrer Funktion definiert. An dem Punkt ähnelt es ein ganz klein wenig Colorforth, aber geht mit Sicherheit nicht so radikal ans Werk. Ist auch mein erstes Forth und deshalb wahrscheinlich ein wenig jenseits des Forth-Mainstreams... (Sofern man bei Forth in seiner Abgeschiedenheit überhaupt von einem Mainstream sprechen kann!)

drohne235 hat geschrieben:Dabei verstehe ich unter einem Grundsystem ein System, mit welchem man wirklich autark (Editor, Quelltextverwaltung, Dateiverwaltung) auf dem Hive arbeiten kann. [...] aber es können natürlich mehrere COG's parallel Forthcode abarbeiten. Dafür kann m schon mit nativen Worten mit den anderen Chips und dem eRAM kommunizieren, was bei PropForth ja Metadefinitionen waren.

Das hört sich sehr interessant an! Das wäre dann also wirklich ein Forth-System im Sinne eines rudimentären Betriebssystems, d.h. Dateiverwaltung und Anwendungserstellung.
Ist es eigentlich in Assembler realisiert oder auch in Forth?

drohne235 hat geschrieben:Da ich im Gegensatz zu einem klassischen Forth verschiedene Dinge in die anderen Chips ausgelagert habe, ist m halt ein wenig anders. So läuft der Parser und Screeneditor in Bellatrix und liefert an m vorgeparste Token, bei der Eingabe werden diese schon mit Farben quasi vom Programmierer in ihrer Funktion definiert. An dem Punkt ähnelt es ein ganz klein wenig Colorforth, aber geht mit Sicherheit nicht so radikal ans Werk.

Gibt es zu dem System Dokumentation, bzw. ist eine Beta verfügbar? Im Prinzip ist das ja dann wirklich wie bei einem Jupiter ACE, einschalten und: Forth!

Kann man den mit dem neuen System z.B. einen Task an einen COG schicken und dann das Ergebnis wieder einsammeln? Also quasi Multiprocessing betreiben?

Im Prinzip ist das ja dann wirklich wie bei einem Jupiter ACE, einschalten und: Forth!

Genau da möchte ich hin, dass ist der Traum! Einschalten und Forth - cooler Spruch. Schon bei PropForth hatte ich ja den Jupiter ACE im Blickfeld, weil mich dieses Gerät und Forth schon immer fasziniert haben. Und für die fragmentiert denkenden Nutzer gibt es dann immer noch TriOS mit Spin und monolithischem Compiler.

Das hört sich sehr interessant an! Das wäre dann also wirklich ein Forth-System im Sinne eines rudimentären Betriebssystems, d.h. Dateiverwaltung und Anwendungserstellung.
Ist es eigentlich in Assembler realisiert oder auch in Forth?

Der Kern von m läuft ja in Regnatix als Master und die primären Worte sind alle in Assembler realisiert. Ich hänge mal meine aktuelle Referenztabelle mit allen bis jetzt realisierten Funktionen an. In den letzten drei Spalten sieht man ob es ein primäres (P) oder sekundäres (S) Wort ist, die Spalten T & I zeigen ob das Wort implementiert (I) und/oder getestet (T) ist.

In den Slavechips Administra und Bellatrix verwende ich Spin-Code, um Bildschirm, Keyboard Dateisystem usw. zur Verfügung zu stellen.

Aktuell läuft halt der innere und der äußere Interpreter, grundlegende Compilerworte und der Parser sowie der Screeneditor in Bellatrix. Also auf gut deutsch: Man kann im Interpreter Kommandos eingeben, also Worte aufrufen, neue Worte compilieren, mit dem Screeneditor einen Screen bearbeiten und speichern. Ach ein ls, lsl, cd, open und close funktionieren schon. Der nächste Schritt wird es sein, die bearbeiteten und auf SDCard gespeicherten Screens zu compilieren. Aber dafür mußte ich erstmal eine kleine Pause einlegen...

Multiprozessing: Ich will in Regnatix auf allen verfügbaren COG's m starten, aber nur eine "Main-COG" wird dabei interaktiv zugänglich sein. Mein Plan: Die anderen COG's werden auf einem Steuerwort "geparkt" und bei Bedarf kann mit einem Kommado/Wort in diesen ein beliebiges anderes Forthwort gestartet werden. Was sie dann in diesem Wort tun, steuert der entsprechende Forthcode. Sie könnten also bestimmte Werte berechnen und die Ergebnisse in einer Variable ablegen oder ähnliches. Was schwieriger wird, ist die parallele Nutzung der Slave-Ressourcen - ist allerdings nicht unmöglich, sondern ich habe momentan einfach noch nicht den Aufwand betrieben, diese Ressourcen per Semaphore zu verriegeln. Im PropForth habe ich mit diesen Möglichkeiten gespielt, was die Sache aber ziemlich komplex macht. Ich denke aber, das macht auch keinen wirklichen Sinn bei so einem kleinen Computer wie dem Hive, wird wohl mehr was für den Hive II...

Da mental und m mehr mein Privatvergnügen ist, gibt es da auch kein Repository, aber das kann ja noch werden. Wenn du es dir mal anschauen möchtest, kann ich meinen aktuellen Entwicklungsstand mal packen und hier anhängen!?

Wie gesagt: Hört sich klasse an!

Vielen Dank für die Übersicht, scheint ja doch schon recht weit gediehen zu sein. Kleiner 'bug' übrigens: s/defination/definition/ (IMHO).

Würde das System gerne testen. Allerdings: Habe erst vor kurzem von Hive gehört und muss jetzt mal in die Gänge kommen und einen bauen. Muss mich mal mit ein paar Leuten besprechen, vielleicht bauen wir gleich mehr als einen - ist ja ein "Aufwasch"

Gerade bin ich noch mit diesem (sehr kleinen) System beschäftigt:
http://www.forth-ev.de/wiki/doku.php/pr ... e4th:start

Ich habe mir erlaubt das bei der Forth Gesellschaft e.V. zu verlinken...

http://www.forth-ev.de/