HIVE-Project

paulruiz hat geschrieben:[1] TriOS
Vielleicht konnen wir anfangen mit das eRAM in zwei Teilen: 0.5MB fur TriOs und Ramdisk und 0.5MB fur XMM.

Mir geht da eine andere Idee nicht ausm Kopp: Warum nicht ${PROGRAMMNAME}.xmm als XMM-Speicher eines Prozesses nehmen? Ein das XMM cachender Subprozeß würde sich schon d'rum kümmern daß nur dieses File benutzt würde und keine anderen Bereiche der RAMDisk...
Man käme so vielleicht sogar in Bereiche wo unter XMM-Appliaktionen ein begrenztes Task-Switching möglich wird.
Ich denke da nicht an paralleles Musik-Abspielen und Kompilieren (also schnelles Umschalten), sondern ganz grobes Taskswitchen wie z.B. den Editor mit dem bearbeiteten File einfach weiter laufen lassen, das File lediglich speichern, den Editor in den Hintergrund drücken (oder vielleicht gäb's auch bald umschaltbare Terminals à la Screen oder TMux?) und den Kompiler anwerfen... eher Task-Swapping als Switching... aber es wäre schon handlich... selbst wenn der Hintergrundprozeß nur eingefroren wäre derweil... und XMM-Prozesse wären persistent wenn alles was zum Restart gebraucht würde sein XMM-File plus der Interpreter der virtuellen Maschine wäre...

Zwei Dumme, ein Gedanke. Primär hatte ich nicht vor, eine Ramdisk für TriOS zu schreiben, sondern ich wollte eine Speicherverwaltung für Spin-Programme, welche unterTriOS laufen und es war mehr mit Blick auf die Verwaltung von Daten gedacht, da die Spinprogramme im hRAM laufen. Aber die Idee ist ähnlich deiner Vorstellung - die Speicherverwaltung als Minidateisystem.

Mein Plan für die Sache im TriOS sah in etwa so aus: Ein TriOS-Programm, wie zum Beispiel ein Editor, kann sich im eRAM Speicher anfordern, indem es in der Ramdisk eine Datei mit passender Größe erzeugt. Auf diesen Speicher kann dann wie bei einer Datei sequentiell per rd_get/put/seek zugegriffen werden, oder direkt per Adresse, wobei in diesem Modus die Adresse $0 dem ersten Byte des Speicherblocks entspricht. Wenn der Editor verlassen wird, kann wahlweise die Speicherdatei erhalten bleiben. In der Kommandozeile kann man die Dateien/Speicherblöcke über das xdir-Kommando anzeigen und mit xload/xsave/xdel rudimentär verwalten. Dabei kann jede Speicherdatei über ihren 8+3-Dateinamen angesprochen werden. Startet man ein anderes Programm, zum Beispiel einen Compiler, so kann dieser die Daten in den Dateien/Speicherblöcken weiter verarbeiten. Startet man wieder den Editor, geht es weiter mit der Textbearbeitung usw. Ach ja: Bei dem Speicherdateisystem verwende ich auch Filedeskriptoren und es können mehrere Dateien geöffnet werden.
Die Ramdisk ist dabei als verkettete Liste von der niedrigsten Adresse aufsteigend realisiert. Von der obersten verfügbaren Speicheradresse absteigend habe ich die Systemvariablen von TriOS angeordnet. Der freie Bereich zwischen Ramdisk und Systemvariablen kann auch von Programmen genutzt werden, ist aber nicht resident und wird eventuell überschrieben, sobald sich etwas in der Ramdisk tut. Diesen Bereich habe ich für einen einfachen und unkomplizierten Zugriff vorgesehen, der nicht so kompliziert wie der Zugriff auf die Ramdisk dafür aber "vogelfrei" ist.

Was man mit diesem Modell nicht direkt machen kann, ist eine feste Zuweisung eines Speicherblocks zu einer physischen Adresse. Da braucht es dann ein anderes Modell. Im Prinzip ist diese Geschichte mit der Ramdisk auch mehr ein Versuch von mir eine verwendbare Speichervarwaltung zu realisieren. Ich bin halt nicht der große Softwarespezialist, das sind auf dem Gebiet vielmehr meine ersten Schritte... In PASM als MMU ist das eine ganz andere Sache als in Spin. Der momentane Satus ist je nur von TriOS aus gedacht und alle Zugriffsroutinen für den eRAM sind in Spin realisiert, also auch entsprechend langsam. Kann sein das die Idee mit der Kombination von Ramdisk und Speicherverwaltung als verkettete Liste Murks ist, dann muss eine bessere Variante her.

Die Aufteilung von Funktionen auf die physischen RAM-Bänke fand ich aus folgendem Grund dennoch sehr interessant: Um Hardware zu sparen, findet ja die Adressdekodierung des obersten Adressbits im Hive per Software statt, indem direkt die Signale /RAM1 & /RAM2 programmiert werden. Wenn man für jede Funktion (TriOS/XMM) eine RAM-Bank verwendet, so kann man sich diesen Aufwand in den Zugriffsroutinen zur Ansteuerung des RAMs sowohl im TriOS als auch in den anderen Systemen sparen - es wird einfacher und schneller bei jedem Speicherzugriff und man könnte TriOS und andere Systeme mit eigenem Speicherzugriff sauber trennen, ohne die Speicherverwaltung von TriOS komplett umzubauen. Nachteil ist dann die Begrenzung auf 1/2Meg Speicher.

Eine andere Variante wäre ja, den Regnatix-Code von TriOS komplett zu beenden, wie ich das schon oben geschrieben hatte. Dann hätte man nur noch den TriOS-Code in Administra und Bella laufen und die Schnittstelle zum eigenen System wäre dann der Bus.

Die Idee von paulruiz (0.5MB fur TriOs/Ramdisk und 0.5MB fur XMM) fand ich eigentlich ganz gut. Es müsste nicht unbedingt 50/50 sein, 256 KB für XMM würden auch eine Weile reichen. Wenn dies aber mit der Aufteilung in physischen RAM-Bänke zusammenpasst, könnte doch ein Schuh daraus werden.
Meine Vorstellung vom XMM-Cache-Prozess ist ganz klar ein PASM-Programm, was einfach nur Code 1:1 vom eRAM ins Hub-RAM kopiert (z. B. 4K reserviert). Eine fixe Adressvergabe im XMM wäre aus Performance-Gründen von Vorteil.

Ich weiß nur noch nicht, wie sich die Prozesse/COGs für XMM und TriOS den Bus teilen und sich nicht gegenseitig ins Gehege kommen?
Mir ist noch nicht klar, wie ich die RAM-Disk als Datenspeicher nutzen könnte, aber falls, z. B. der Compiler seine Symboltabellen in der RAM-Disk verwaltet und gleichzeitig XMM für Code nutzt, müssten die Zugriffe aufs eRAM koordiniert ablaufen.

Ich habe weiter am XMM Konzept gearbeitet (hört sich blöd an, ist ja keine Arbeit, sondern Freizeit)
Bisher ist es mir gelungen, mit Hilfe von 2 COGs an die 5 MB/s vom eRAM in HUB-RAM zu kopieren (Auszug zum Kopieren von 4 Bytes).

COG1: COG2: Dies wird je nach CacheLine-Größe (im Moment 16 longs) n-mal nacheinander ausgeführt.
Es funktioniert soweit gut. Aufbereitung der Adressen sowie die Ansteuerung des Adress-Latches habe ich weggelassen. Dieser Overhead kommt noch hinzu. Daher sind es weniger als 5 MB/s.

Kann dies noch beschleunigt werden?

Die Small-C VM arbeitet aber mehr Opcode/s ab, als über die Cache-COGs "nachgefüttert" werden können. Daher muss ich mir ein echtes Cache-Verfahren einfallen lassen, bei dem oft genutzte Sequenzen im Cache liegen.

Gibt es dazu Ideen?

josto hat geschrieben:

Code: Alles auswählen

                    nop
                    add     tmp1, #$100
                    mov     OUTA, tmp1
                    nop

outa verhaelt sich normal, i.e. Du kannst hier add outa, #$100 nutzen.

josto hat geschrieben:COG2:

Code: Alles auswählen

                    add     DstAddr, #1 
                    mov     tmp2, INA 
                    wrbyte  tmp2, DstAddr 
                    add     DstAddr, #1 
                    mov     tmp2, INA 
                    wrbyte  tmp2, DstAddr 
                    add     DstAddr, #1 
                    mov     tmp2, INA 
                    wrbyte  tmp2, DstAddr 
                    add     DstAddr, #1 
                    mov     tmp2, INA 
                    wrbyte  tmp2, DstAddr 

Kann dies noch beschleunigt werden?

Setzt voraus das der RAM schnell genug ist (sollte es aber sein). Der folgende code ist nicht auf meinem Mist gewachsen:
Leicht asymmetrisch aber bringt Dir 6.6MB/s (one long every 3 hub windows). Das ist aber noch nicht das Ende der Fahnenstange. Mit entsprechend schnellem RAM sind 20MB/s drin. HTH

Mit "movs" hatte ich auch schon probiert. Das 9.Bit war aber immer im Weg. Dies über das Carry zu lösen, ist eine super Idee.

In der Zwischenzeit hatte ich auch mit dem Gedanken gespielt, noch einen dritten COG zu verwenden (Hive hat ja ausreichend davon), so dass ein COG die Adresse inkrementiert und 2 COGs abwechselnd die Daten lesen. So müssten 10MB/s machbar sein. Allerdings muss man hier spezifische COGs auswählern (z. B.: 2, 6, 7), so dass das Timing der RAMs nicht verletzt wird.

Ein weiterer COG würde ich für den Systembus zu Bellatrix und Administra spendieren. Dann bleiben immer noch 4 COGs für C-Programme, welche sich um den/die/das/(?) Cache streiten.
Wie dies gehen soll, ist mir im Moment auch noch nicht klar?

josto hat geschrieben:Ich weiß nur noch nicht, wie sich die Prozesse/COGs für XMM und TriOS den Bus teilen und sich nicht gegenseitig ins Gehege kommen?

TriOS (oder besser die IOS-Lib) ist momentan nicht auf einen geteilten Bus ausgelegt. Im propForth habe ich ein wenig mit diesen Möglichkeiten experimentiert, da dort ja mehrere Forthsysteme in den COGs parallel laufen. Wenn man das auf die IOS-Lib oder etwas analoges unter C überträgt, muss man alle Buszugriffe über Locks verriegeln. Unter Forth hat das als Experiment ganz gut geklappt (siehe hier: http://hive-project.de/content/1983#more-1983), wobei es letztlich aus Anwendungssicht kaum Sinn macht. Da die XMM aber ein transparent neben der Anwendung laufender Hintergrundprozess ist, wird das wieder interessant.

Genau wie josto gebe ich eine Idee nicht so einfach auf. Hab doch das hive spin compiler ausgeschrieben um es aus meinem Kopf zu bekommen
Anbei die Quellen. Es ist gerade Fertig, also nicht poliert oder fehlerfrei, aber es uebersetzt meinem CVM Quellen fehlerfrei.

Ich hab nur sehr normales C benutzt, ich hoffe das mit der josto C Compiler auch ein Hive autarken Spin Compiler moeglich wird. Es sind etwa 5000 Zeilen und ist ein etwa 50KB binary auf x86.

Paul

Hallo paulruiz

Super Arbeit, Respekt!

Ich habe den Compiler unter Linux compiliert und angetestet (siehe Anhang). Das generierte Binary ist gleich lang, sieht aber etwas anders aus, als das was BSTC generiert. Funktioniert hat es bisher leider auch nicht(LED blinkt nicht). Mache ich was falsch?
Ich habe dir beide Varianten angehängt und auch das Spin-Programm dazu.

Dein Compiler lässt sich leider noch nicht mit Small-C übersetzen, hier fehlt bei Small-C noch einiges an Funktionalität, wie z. B. Strukturen. Im Moment arbeite ich immer noch am Backend (XMM/Cache-Betrieb). Daher hat sich am Frontend noch nichts getan.
Wenn du Lust hast, kannst du dem Compiler gerne die fehlenden Dinge "beibringen"

Danke fur das Test. Ich hab ein Fehler mit _clkmode (sehe Ende von link.c).
Versuch mal ohne das CON Blok.

Paul

PS Ohne CON lauft der Propeller mit 12Mhz. Vielleicht muss es auch >>11 stat >>14 sein.