Ich hatte einen Traum...

[paulruiz]

Anbei eine Idee um eine CPU cog und eine MMU cog zu synchronisieren. Meine Hive ist nog nicht fertig und PASM ist neu fur mich, also alles völlig ungetested. Das Idee ist um ein I/O pin (nur das heartbeat led is nog frei) zur synchronization zu benutzen, und um das CPU cog an ausführung einer instruktion arbeiten zu lassen, weil das MMU cog der nächste instruktion bearbeitet.

Paul

Code: Alles auswählen

CPU Cog:
start       wrlong  mmu_addr, pc
              or          outa, #htbeat
              add       pc, #4
              andn     outa, #htbeat
loop       waitpne  #htbeat, #htbeat
              rdlong   mmu_data, instr
              wrlong  mmu_addr, pc
              or         outa, #htbeat
              add      pc, #4
              andn    outa, #htbeat
              /* decode & process 'instr' here*/
              jmp      #loop

MMU Cog:
loop       waitpeq #htbeat, #htbeat
              or          outa, #htbeat
              rdlong   mmu_addr, addr
              /* access external RAM here */
              wrlong   mmu_data, data
              andn      outa,#htbeat
              jmp        #loop

Hive Experten, funktioniert so etwas?

Paul

[josto]

..wie das so ist mit Träumen, nicht alle werden wahr.

Ich habe mal die RAM Anschaltung und eine mögliche XMM Realisierung angedacht. Selbst wenn man 2 COGs parallel schalten würde, die Hand in Hand arbeiten (einer generiert die Adressen, der andere liest die Daten), komme ich nur auf einen Durchsatz zw. 4 und 8 MB/s. Das wären ein bis zwei 32-Bit-Befehle pro µs. Der Main-COG würde sich da absolut langweilen, wenn es einfache Propeller Instruktionen wären.

Es macht daher doch Sinn, entweder komplexere Instruktionen zu definieren, so dass weniger Code geladen werden muss und der Main-COG gleichzeitig gut ausgelastet ist, oder in Richtung ZOG oder ähnliches zu gehen und 8-Bit Instruktionen zu verwenden.

Oder beides gleichzeitig, also 8-Bit-Instruktionen, die möglichst optimal auf den Compiler zugeschnitten sind, so dass eine optimale Code-Dichte erreicht wird.

In diesem Zusammenhang werde ich mir den Small-C Compiler nochmals ansehen. Evtl. lassen sich die pcodes des Compilers doch direkt in eine VM für den Prop umsetzen.

PS: HIVE Nr. 289 ist teilbestückt. Ich kann ihn nur noch nicht testen, da mein PC keine RS232 mehr hat.

[yeti]

Ich habe mal die RAM Anschaltung und eine mögliche XMM Realisierung angedacht. Selbst wenn man 2 COGs parallel schalten würde, die Hand in Hand arbeiten (einer generiert die Adressen, der andere liest die Daten), komme ich nur auf einen Durchsatz zw. 4 und 8 MB/s. Das wären ein bis zwei 32-Bit-Befehle pro µs. Der Main-COG würde sich da absolut langweilen, wenn es einfache Propeller Instruktionen wären.

PropGCC generiert Code der XMM im HubRAM cacht und dort ausführt.

VMCog abstrahiert Sowas für verschiedenen Einsatz (hat aber selbst nix direkt mit PropGCC zu tun)...

http://propgcc.googlecode.com/hg/doc/Memory.html mag noch als Inspiration dienen...

http://code.google.com/p/propgcc/wiki/PropGccLoader zeigt unter Anderem Timimg-Angaben einer Demo in verschiedenen Speichermodi...

[josto]

An Paul:

Ich verstehe deine Idee zur MMU nicht so ganz, speziell die heartbeat LED.

Zur Synchronisierung dachte ich nur an zwei 32-Bit Register im Hub-RAM:
- HubAddrReg als Adresse in RAM
- HubDataReg für die Daten Daten vom RAM

Der Main-Cog schreibt HubAddrReg und liest aus HubDataReg. Der MMU Cog vice versa.
Immer wenn die Daten gelesen wurden, wird das Register auf Null gesetzt.
Dies setzt sowohl für Daten (Instruktionen) als auch Adressen voraus, dass diese nie Null werden. In C ist Null sowieso eine ungültige Speicheradresse.

Die Idee war, dass der MMU Cog nach einem Lesevorgang bereits die nächste Adresse im RAM einliest. Taucht im HubAddrReg diese Adresse auf, kann er sofort reagieren, Im anderen Fall muss er den Wert zur neuen Adresse neu einlesen, seine Pipeline quasi verwerfen.

Damit hätten wir eine zweistufige Pipeline.

Für den MMU-Vorgang dachte ich an zwei Cogs die parallel arbeiten, um die Sache zu beschleunigen.

An yeti:

Die oben genannte Lösung scheint mir relativ leicht zu implementieren. Eine echte Cache Lösung im HUB-RAM scheint mir schwieriger, auch aus persönlicher Erfahrung mit diversen Mikrocontrollern . Da würde ich lieber die Finger weglassen. Außerdem habe ich Bedenken, dass die zusätzlich notwendige Logik die Sache wieder unnötig ausbremst.

Vorstellbar wäre noch, dass einzelne Schleifen in C mit

Code: Alles auswählen

#pragma START_CACHE
... 
#pragma STOP_CACHE

markiert werden, Diese Sequenz würde dann im Hub-RAM zwischengespeichert und mehrfach ausgeführt. Macht aber nur bei kurzen Sequenzen Sinn.

[drohne235]

VMCog abstrahiert Sowas für verschiedenen Einsatz (hat aber selbst nix direkt mit PropGCC zu tun)...

Hab noch nicht verstanden wie das funktionieren soll. Hat sich schon jemand die VMCog genauer angeschaut?

Zum externen RAM: Was wäre wenn man für die Codeausführung den schnellen Hubram nutzt, und einen schnellen Swapmechanismus zum eRAM für Module einbaut? So ein gesteuerter Blocktransfer zwischen internem und externem RAM sollte auch recht schnell sein, da man ja ein zusammenhängenden Adressbereich (Increment direkt am Adressport!) transferiert. Bei der Programmierung muss man seine Software halt in maximal 32 KB Module sinnvoll aufteilen, eventuell etwas kleiner um globale Variablenbereiche zu realisieren. Die Programmausführung aus dem Hubram bekommt man bei einfacherer Struktur als Spin (keine Objekte) auch etwas schneller denk ich mal. Zumal ein einfacherer Zwischencode auch eine einfachere Codegenerierung bedeutet. Anfangen kann man ja dann mit einem Assembler für diesen Zwischencode, bzw. für diese viruelle Maschine. Damit könnte man schon programmieren und experimentieren um zu schauen ob es was bringt. So einen Assembler samt Debugger und Monitor in Spin zu schreiben ist nicht sehr schwierig denk ich.

[yeti]

Die oben genannte Lösung scheint mir relativ leicht zu implementieren. Eine echte Cache Lösung im HUB-RAM scheint mir schwieriger, auch aus persönlicher Erfahrung mit diversen Mikrocontrollern . Da würde ich lieber die Finger weglassen. Außerdem habe ich Bedenken, dass die zusätzlich notwendige Logik die Sache wieder unnötig ausbremst.

Hast Du die Timing-Werte der PropGCC-Beispiele beäugt?
Hälst Du die PropGCC-Leute für Idioten die ihre Zeit in eine Sackgasse stecken wollen?

[josto]

An yeti

Hast Du die Timing-Werte der PropGCC-Beispiele beäugt?

Welche meinst du, die aus dem Link oben? Ich kann mit den Zahlen nix anfangen.

Hälst Du die PropGCC-Leute für Idioten die ihre Zeit in eine Sackgasse stecken wollen?

Ich verstehe deine Frage nicht.

[drohne235]

Ich verstehe deine Idee zur MMU nicht so ganz, speziell die heartbeat LED.

Im Prinzip eine ähnliche Idee wie du hast: Im hRam befinden sich zur Kommunikation die Variablen mmu_data und mmu_addr. Der Unterschied besteht im Startsignal für die MMU.

Wenn ich es recht verstanden habe muss bei deiner Lösung die MMU ständig in einer Schleife schauen ob sich etwas an der Adresse ändert um dann zu reagieren.

Die Lösung von paulruiz nutzt ein Port (HBeat-LED) um der MMU zu signalisieren, sie solle doch die Daten aktualisieren bzw. aus dem RAM lesen. Der Vorteil liegt in der Möglichkeit den Maschinencodebefehl waitpeq zu verwenden. Dieser Befehl stoppt die Programmausführung, bis eine bestimmte Portkonstellation auftritt - in unserem Fall der Impuls an HBeat. Die Reaktionszeit ist dabei minimal und absolut determiniert.

Allerdings hab ich dieses Port gerade für die IO-Karte vorgesehen, sofern man weitere IO-Props parallel am Bus anschließen möchte...

[josto]

An drohne235

Im Prinzip kann ich dir nur Recht geben. Ich stelle mit die Aufteilung der Software in "Cache-bare Happen" aber schwierig vor.
Ein typisches C-Programm besteht aus sehr vielen kleinen Funktionen, die sich im Extremfall wild untereinander aufrufen. Wenn der Compiler dies erkennen soll, müsste er eine Call-Tree-Analyse machen, um zu wissen, was wann in den Cache geladen werden soll.

Wenn es spezielle Anweisungen gäbe, mit denen der Programmierer definieren kann, welche Funktion wo im Cache abgelegt werden soll, hat er das Problem, bei seinen Funktionen nicht den Überblick zu verlieren, bzw. zu wissen, wieviel in den Cache passt.

Vielleicht sehe ich das aber auch nur zu komplex...

Aber wie du schon sagt, das Ganze wäre ausbaufähig. Man könnte mit LMM starten und das Konzept bei Bedarf schrittweise ausbauen.

Edit: Danke für die Nachhilfe bzgl. dem WAITPEQ, den Befehl hatte ich noch nicht gefunden

[drohne235]

Im Prinzip kann ich dir nur Recht geben. Ich stelle mit die Aufteilung der Software in "Cache-bare Happen" aber schwierig vor.

Ich glaube ich schmeißen grad alle möglichen Ideen durcheinander, weil ich bei diesem Thema auch keinen richtigen Plan habe. Mit den Modulen war ich schon wieder bei einer etwas anderen Idee. Ich dachte dabei weniger an einen Cachemechanismus welcher automatisch im Hintergrund läuft, sondern vielmehr an Programmmodule auf einer höheren funktionalen Ebene. Den Modulwechsel findet dann auch unter Programmkontrolle statt. So wie bei einem Game, wo der Titelscreen ein Modul sein kann, wie auch die einzelnen Level, die entsprechend der Situation geladen und gestartet werden. War halt so die Idee, dass die virtuelle Maschine vielleicht gleich einen solchen schnellen Modulwechsel als Befehlscode unterstützen könnte. Naja, war eine blöde Idee und passt auch nicht wirklich zum Thema...