HIVE-Project

Halloe.

Ich sammle gerade ein paar Ideen zusammen, die ich für ein neues Hive- Betriebsystem umsetzen möchte.

Das ganze Betriebsystem wird im Grunde genommen rein in Propeller- Assembler geschrieben sein. Für die Programmentwicklung werden Editor, Compiler und Assembler direkt auf dem Hive zur Verfügung stehen. Compiler und Assembler werden keine SPIN- Objekte erzeugen, sondern einen eigenen Weg bei der gestalltung des fertigen Codes gehen.

In dem zusammenhang würde mich interessieren, wie sehr Ihr hier an der Programmiersprache SPIN hängen würdet ?

Muss das Betriebsystem unbedingt schnittstellen zu Spin bereit stellen und das starten / laufen lassen von SPIN- Anwendungen aktiv unterstützen ? Im Grunde genommen würde so ein SPIN- Support die Basisschnittstellen des Betriebssystems sicherlich um einiges Aufblähen und ggf. einige der optimierungen die ich mir durch einen eigenen Compiler/Assembler verspreche wieder zu nichte machen. Eine möglichkeit aus dem Beriebsystem heraus alle 3 Propeller mit einem anderen Betriebsystem wie z.B. dem "original"- Hive-OS zu startet würde es natürlich geben.

Auch möcht ich hier natürlich keinen dazu Zwingen für mich passende Anwendungen zu schreiben, oder mein neues OS zu benutzen. Mir gehts bei meiner Eigenentwicklung rein um den dabei zu erzielenden Lerneffekt. Ich möcht mal ausprobieren, was man aus dem Hive so rauskitzeln kann, wenn man das ganze Hardwarenah umsetzen würde.

Grüße
Janaha

Soweit ich es verstanden habe, ist der Spin-Interpreter in die Hardware(!) des Propellers integriert, und PASM-Code lässt sich auch nur innerhalb eines minimalistischen Spin-Rahmens ausführen. Insofern müsste doch die Spin-Unterstützung durch das OS ziemlich simpel bzw. sogar notwendig sein. Programmiersprachen werden doch üblicherweise ohnehin auf Anwendungsebene implementiert und nicht auf OS-Ebene ...

Zudem rechne ich mit einer sehr geringen Akzeptanz des OS, wenn man keine eigenen Spin-Programme ausführen könnte. Spin ist ja wesentlich besser an die Propeller-Architektur angepasst als jede andere Hochsprache, insofern gibt es keinen Grund, einfache Programme, die nicht Performance-kritisch sind, nicht in Spin zu schreiben. Außer vielleicht wenn man die Sprache partout nicht mag. Aber ob man dann beim Propeller gut aufgehoben ist ...?

Oder geht es darum, ob Spin-Funktionen direkt ins OS integriert werden können? Da könnte ich mir durchaus vorstellen, PASM zur Pflicht zu machen, denn ein OS sollte immer Performance-optimiert sein. Ich denke, dass wir das aktuelle OS auch nach und nach in PASM übersetzen werden.

Ja, der SPIN Interpreter ist ein kleines Programmstück im ROM der Propellers, der nach dem Start des Propellers losläuft. Daher müsste für den Start ein minimaler SPIN- Code von 7 Longs am beginn des Betriebssystems stehen. Diese 7 Logs dürfen nach dem Start des Assemblersystems von selbigem problemlos überschrieben werden. Das Turbulence- Demo ist z.B. so geschrieben. Die 7 Longs werden nach dem Start der Hauptanwendung einfach als Variablenpuffer mit verwendet. Nach diesem "kurzstart" ist vom eigentlichen Spin sozusagen nichts mehr über. Man kann danach eigentlich komplett ohne Spin auskommen. Bei einem Mischbetrieb mit Spin und Assembler, wo sich sozusagen beide jederzeit gegenseitig aufrufen können sollen bekommt man schnell probleme mit dem COG- internen Ram, das man vor einem Sprung nach Spin erst komplett retten muss, da es durch den Spin- Interpreter überschrieben würde. Meine Lösung könnte am Ende Funktionsblöcke aus dem EEPROM bzw. RAM und SDCARD nachladen, ohne immer gleich den ganzen COG-Ram neu beschreiben zu müssen. Das würde bei der Laufzeit ne menge an Resourcen einsparen. Vor allem möchte ich es auch irgendwie hinbekommen, das die COG's möglichst optimal mit ihrem RAM umgehen. So möchte ich z.b. versuchen den optimierer später die einzelnen Funktionen zu kleinen Library- ähnlichen Objekten zusammen zu packen und das ganze dann auch noch so das Funktionen die sich gegenseitig aufrufen möglichst dicht zusammen liegen, so das bei Unterprogrammaufrufen so wenig wie möglich in das COG- Ram nachgeladen werden muss. Bisher habe ich noch nicht angefangen wirklich zu Programmieren, ich bastle gerade noch an meinem Gehäuse rum, aber man kann ja schonmal ein wenig träumen.

Grüße
Janaha

So viele HiVe-Linge sind Profis und haben schon immer mal über ein eigenes OS nach gedacht / geträumt.
Ich sehe es schon kommen in ein par Monaten beim Linux Stammtisch
"Na Joshy was ist denn das dar mit dem HiVe"
Klasse Sache macht echt spass und es gibt 11 verschiedene OS's dafür.
"Oh hört sich ja gut an und wie sind da so die Programme für?"
Keine Ahnung kenne nur eine Hand voll Demos.

Grüsse Joshy

Finde ich eine sehr interessante Sache, unabhängig ob es letztlich jemand nutzt. Ich denke gerade bei einem solchen Experimental-OS sollte man sich erstmal von nichts weiter beeinflussen lassen ausser von den eigenen Interessen und Vorlieben. Wenn ich mein iSpin betrachte war es auch nur ein Experiment für mich um zu verstehen wie Forth intern funktioniert - und genau diese Informationen hat es mir gebracht, auch wenn es in seiner jetzigen Form unbenutzbar ist und wohl bald in der digitalen Tonne landet.

Und hätte ich über den praktischen Nutzen nachgedacht, als ich vor ein paar Monaten den Hive zusammenlötete, dann hätte es keinen Hive gegeben. Wenn man schon am Anfang versucht alles zu beachten, begrenzt man sich selbst viel zu sehr und es kommt nur ein Clone von bestehendem heraus. Entscheidend dabei ist nur eins: Spaß an der Freude, dann wird es auch was.

Entschuldige wenn ich da mal ein wenig deinen Thread hier mißbrauche: Ich bastle heimlich ja auch ab und an an einem solchen Experiment, hab mal eine Skizze angehängt. Das ganze dient einfach nur als Spielerei und um einen Einstieg in PASM zu bekommen - ich kann das echt nicht theoretisch, sondern brauche da immer was praktisches was mich motiviert. Die Idee dabei war folgende: Mit den acht Cogs haben wir ja acht kleine Subsysteme und man kann ja so acht Miniprogramme starten. Einen Task habe ich für das System reserviert - die iCog. Dieser Task muß sich stellvertretend für die anderen Cogs zentral um die Kommunikation zu den Slaves, um das Speichermanagment und die Verwaltung der Cogs kümmern. Für ein kleines CogOS wäre es sicher schonmal ausreichend mit den sieben verbleibenden parallelen Tasks arbeiten zu können.

Und damit so eine Spielerei auch richtig Spass bringt gibt es natürlich in diesem Experiment eine kleine Herausforderung: Wäre es möglich in einer Cog einen CLI laufen zu lassen? Wäre das möglich? Die Vorstellung gefällt mir, quasi ganz direkt in einer Cog interaktiv zu arbeiten - keine Ahnung ob man das hinbekommt. Aber reizvoll wäre eine solche Sache für mich schon und ich denke, wenn man schon diese beiden Komponenten hinbekommt - iCog und CLI - dann hat man schon einiges von PASM verstanden.

Aber dann geht es ja weiter. Man kann dann winzige Microcodeprogramme mit einer Größe von 512 Longs von SD-Card laden und in einer Cog laufen lassen. Was nun? Wie weit würde man mit einem so minimalen Setting kommen? Könnte man in einer Cog einen Speichermonitor laufen lassen? Würde es vielleicht sogar für einen Assembler oder Editor reichen? Da wird es schon ziemlich schwierig denke ich, aber wäre es unmöglich?

So, ich möchte auch mal meine Senf dazugeben.
Betriebsystementwicklung ist bestimmt spannend, wenn auch nicht wirklich mein Ding. Ich erweitere sowas gerne, aber "from scratch" will ich sowas nicht machen.
Gut, ist ja soweit kein Problem, solange es, neben euren "JanOS, DJ-Hellfire-OS und drohne235_OS_wo_forth_drin_ist" irgendein Standard-OS da ist.
Also eins von dem ich weiß, das es in 2 Stunden auch noch da ist, anähernd so funktioniert wie vor 1 Stunde ... und vor allen Dingen, ich nicht alles was ich bis dahin an Anwenderprogrammen programmiert habe bei dem einen halb läuft, beim anderen gar nicht und bei dem dritten den Schreibtisch explodieren lässt.

Ich hasse Sätze wie "Diese Programm benötigt Erweiterungsmodul "Vollhonk Deluxe" + dreieckigen Bildschirm und man muß einen Inkubator anlegen".
Ich will einfach auf dem bestehenden IOS eine Anwendung programmieren und das läuft, weil ios der Standard auf dem Hive ist. Wer ein anderes OS hat, hat entweder Pech gehabt, muß ios laden, oder auf Anwendungen für sein OS warten.

Ich bin eher dafür, IOS weiterzuentwickeln. Ich sehe hier die ganzen guten OS-Programmierer irgendwelche abstrakten OS'se entwerfen und ios stirbt über kurz oder lang.
Babylon lässt Grüßen. Lauter Einzelkämpfer mit "ihrem" Betriebssystem und keiner versteht den anderen (Softwaretechnisch).
Für mich persönlich ist ein OS immer nur Mittel zum Zweck .. vielleicht habe ich deshalb eine etwas andere Einstellung.

Versteht mich nicht falsch .. natürlich sollt ihr Spaß haben, Ideen umsetzen und das Non-Plus-Ultra-OS entwerfen .. trotzdem wäre es schön, wenn ios im Gedanken dabei nicht komplett vernachlässigt wird.

[EDIT]
Vielleicht noch eine Anmerkung:
Ein Freak, der ein Freakspiel programmiert, wird ohnehin selbst das beste OS nicht benutzen, weil es ihn zu sehr einschränkt. Der macht ohnehin sein eigenes Ding, war früher schon so, ist heute auch noch so. Also sehe ich gar nciht sooooo den Bedarf an einem hochperformanten, superschlanken, aber dementsprechend "unluxeriösen" OS, das ein "Normalo" gar nicht mehr kapiert oder auch nur dran denken kann, dafür was zu schreiben.
[/EDIT]

Umm .. sorry, grob OffTopic

Gruß.
Rainer

Hallo Rainer.

Keine Angst, wir werden das IOS bei all unserer Bastellei nicht vergessen. Ich gehe mal davon aus, das die meisten Applikationen eh für IOS geschrieben werden. Da müsste die neue Version von Namin und Mir einem was den Komfort und das Aussehen angeht einem wohl schon die Schuhsohlen schon beim Booten weghauen. Wir wollen eher so eine Mischung aus GEOS und dem AMIGA-Betriebssystem machen. Wie viele dann Anwendungen speziel für unser OS machen möchten ist uns eigentlich egal. Gerade für GEOS gabs am Ende ja auch nicht gerade viele Anwendungen. Hab GEOS aber immer gern zum schreiben von Texten genommen. Die Textverarbeitung war für den C64 gesehen schon recht gut. Wie anfangs schon geschrieben uns treibt da eher der Entdeckerdrang.

Und eben wegen unserem Gedanken Multi-OS machen zu wollen haben Namin und ich ja auch die EEPROM- Karte entwickelt. Mit ihrer Hilfe können wir jederzeit alle 3 Propeller mit neuem Bootcode versorgen. Von welcher der 3 EEPROM- Bänke gerade gebootet wurde, ist dabei egal. Die anderen beiden Banken stehen jederzeit am I2C- Buss zur Verfügung. Die Propeller können also jederzeit direkt auf alle 3 an ihnen angeschlossenen EEPROM's zugreifen. Ein kleiner I2C- Loader reicht aus, um einfach von einer der anderen beiden Bänke das IOS bzw. unser System nachzuladen und auszuführen. Wer keine EEPROM- Karte bauen möchte könnte z.B. auch einfach die doppelt so großen EERPOM's direkt auf dem Hive bestücken und könnte immer noch zwischen 2 Systemen hin und her switchen ohne neu Flaschen zu müssen. Evtl. schaft ihr es ja auch noch, das man direkt aus dem IOS heraus alle 3 Propeller komplett mit einer 32KB Binary Datei von SD- Card überschreiben und starten kann. Dann würde der Umweg über mehr EEPROM- Speicher ganz wegfallen. Hm irgendwie kommt mir da gerad ein vieser gedanke für die EEPROM- Karte, mal schaun obs da nen passenden I2C-Chip gibt... da muss ich gleich mal schauen...

Grüße
Janaha

Na dann werde ich Dir mal ein geheimnis verraten ... ich LIEBE Deine Idee von GEOS !

Ich mache mal was, was ich normal nie tue. Ich zeige jemanden meine Ideensammlung (zumindestens einen Teil)
Ich nehme OneNote (keine Diskussionen über MS-Produkte .. ich mags .. außerdem habe ich MSDN und brauch nix zahlen dafür ) als "Brainstorming-Tool" oder "Thinktank" .. wie Du es auch nennen willst.
Ich habe mal eine Seite davon mit genau dem Thema in's Web gestellt .. vieles davon ist einfach schnell "hingeschmiert" ... 'ne Ideensammlung halt.
Ich weiß jetzt nicht ob Firefox und Konsorten .mht anzeigen können .. aber der IE kann's.
http://www.distler.cc/hive.mht

Vielleicht kannst Du da ja ein paar Ideen davon brauchen.

Die "DOS-Shell" versuche ich ja gerade in Regime umzusetzen, aber der Rest oben ist mir "noch" zu heikel

Gruß.
Rainer

Wäre es möglich in einer Cog einen CLI laufen zu lassen? Wäre das möglich? Die Vorstellung gefällt mir, quasi ganz direkt in einer Cog interaktiv zu arbeiten - keine Ahnung ob man das hinbekommt.

Zum Verständnis: Programme laufen doch immer in Cogs, wo sollten sie sonst laufen? Hast du (drohne 235) denn für die bisherige Kommandozeile mehr als einen Cog gebraucht? Ich dachte, so etwas wäre ein ziemlich kleines Programm ...

EDIT: Ich ahne gerade: Du meintest ohne Zugriff auf das Hub-RAM?

laserjones hat geschrieben:[
Zum Verständnis: Programme laufen doch immer in Cogs, wo sollten sie sonst laufen? Hast du (drohne 235) denn für die bisherige Kommandozeile mehr als einen Cog gebraucht? Ich dachte, so etwas wäre ein ziemlich kleines Programm ...

EDIT: Ich ahne gerade: Du meintest ohne Zugriff auf das Hub-RAM?

Genau, ohne Zugriff auf den hRam. Die normale Kommandozeile ist ja ein Tokencode im hRam, welcher von einem Spin-Tokenprozessor in einer Cog abgearbeitet wird. Im Cog läuft also streng gesehen nicht die Kommandozeile, sondern ein Spin-Tokeninterpreter.

Aber das ganze ist eine Spielerei um mit Pasm warm zu werden. Letztlich benutze ich momentan doch zu gern Spin.