Virtueller Hive

Erlebnisse und Schilderungen über die Arbeiten an eurem HIVE.
thiloa
Beiträge: 37
Registriert: So 6. Okt 2019, 21:06

Virtueller Hive

Beitrag von thiloa »

Hallo,
ich baue derzeit einen "virtuellen" Hive auf, d.h. die Propeller ICs und die Peripherie werden in Software (C++) emuliert.
Bisher ist implementiert sind
  • Propeller mit rudimentärem Disassembler/Debugger (läuft derzeit nur als Bellatrix)
  • I2C EEPRom
  • Tastatur
  • VGA (bei manchen Auflösungen derzeit noch leichtes Phasenrauschen)
Anbei ein Screenshot mit dem Tutorial Demoprogramm "test-5-8-bellatrix-matrix"

Die Emulation ist leider recht langsam, aber dafür zyklengenau. Als nächstes werden die serielle Schnittstelle und die SD Karte implementiert.

Viele Grüße
Thilo
Dateianhänge
virtual-hive-1.png
Benutzeravatar
Wuerfel_21
Beiträge: 57
Registriert: Di 21. Jan 2020, 19:20

Re: Virtueller Hive

Beitrag von Wuerfel_21 »

thiloa hat geschrieben: Mi 9. Sep 2020, 23:55 Die Emulation ist leider recht langsam
Wenn 581 kHz die Taktfrequenz ist, dann ist das wohl doch einiges schneller als GEAR. (Wenn du ein ein großes switch/case für die Instruktionen hast, versuch es stattdessen mit computed-goto. Kann/soll schneller sein.)
Vielversprechendes Projekt also.

Außerdem: lustige, obskure CPU-Emulations-Dinge die du vllt. noch nicht beachtet hast:
- Schattenregister unter CNT/PAR/INA/INB und ähnlichen read-only Registern
- undokumentierte Flaggen (z.b. Carry von MOVS/MOVD/MOVI/JMPRET (ist D < S (unsigniert))) (Carry von WRxxxx ist sehr eigenartig, kann aber ignoriert werden, da nicht sonderlich brauchbar)
- ungenutzte opcodes ($00100..$00111) (ich glaube gleiche funktionen wie $00000..$00011 ?)
- Alle Einstellungen in VCFG treten sofort in Aktion - nicht synchron zum Video-takt
- Wenn ein WAITVID verpasst wird, wird was auch immer gerade auf den internen D- und S-Bussen liegt als Video-Daten hergenommen. (stichwort WHOP)
- Schonmal alle ALU-Instruktionen gefuzzt und mit nem echten Propeller verglichen? Hat bei meinem Dingelchen einige Fehler hervorgebracht.
thiloa
Beiträge: 37
Registriert: So 6. Okt 2019, 21:06

Re: Virtueller Hive

Beitrag von thiloa »

Hallo Wuerfel_21,

danke für dein Antwort. Ich habe jetzt mal GEAR auf dem selben Rechner (aber unter Windows statt Linux) mit dem Blinky und dem Matrix VGA Code ausgeführt. Über 30 Sek gemessen kam ich auf eine Taktfrequenz von

Gear:
Blinky: 66 kHz
Matrix VGA Demo: 58 kHz

Hive Emulator (ein Propeller):
Blinky: 1240 kHz
Matrix VGA Demo 570 kHz.

Mit Frequenz meine ich dabei übrigens die Frequenz des Systemzählers (auf dem Hive die 80MHz).

Kommen die Werte bei GEAR so etwa hin oder habe ich da was falsch gemacht?

Bezüglich der "Emulationsgenauigkeit" habe ich mich an die veröffentlichten Verilog Dateien von Parallax gehalten. Die Äquivalenz von meiner Kopie zu den Originaldateien konnte ich für die meisten Teilkomponenten (cog, cog_alu, cog_ctr, cog_vid, hub) mit dem Tool yosys formal verifizieren.

Ich hoffe nur, dass die Verilogdateien von Parallax auch wirklich ihrem Chip in Hardware entsprechen ;)

In der ALU sind mir auch die von dir angesprochenen, undokumentierten Flag Verhalten aufgefallen, bei GEAR scheint das nicht in allen Befehlen korrekt implementiert zu sein. Das WAITVID (WHOP) Verhalten ist bei mir auch der Fall. Der Videogenerator bekommt nämlich von der WAITVID Instruktion genau genommen gar nichts mit. Er gibt nur ein Signal weiter, dass er die Daten von den Bussen genommen hat.

GEAR scheint einen etwas anderen Weg zu gehen, da damals die Originaldateien auch nicht zur Verfügung standen. Hier wird z.B. sowohl der Assembler Code als auch der Spin Code separat ausgewertet. Bei mir hingegen läuft beim Spin Code der original Interpreter aus dem ROM auf der virtuellen COG.

Bei GEAR werden auch die Subschritte eines Befehls nicht wirklich einzeln durchgeführt, sondern er führt alles in einem Schritt durch und wartet dann ein paar Takte. Eigentlich müsste GEAR deshalb zwar etwas weniger originalgetreu aber dafür schneller sein (vor allem bei Spin Code). Eventuell liegt der Geschwindigkeitsunterschied aber auch nur an C# (VM) im Vergleich zu C++?

Ich werden nochmal mit einem Profiler den Hive Emulator durchgehen, um zu schauen, was die meiste Zeit frist. Gefühlt ist bei den Countern noch etwas an Optimierungspotential, unter der Annahme, dass selten alle 16 Counter wirklich aktiv sind.
Benutzeravatar
Wuerfel_21
Beiträge: 57
Registriert: Di 21. Jan 2020, 19:20

Re: Virtueller Hive

Beitrag von Wuerfel_21 »

Kommt etwa hin, bei GEAR muss man auf ein Video-Frame mehrere Sekunden warten, für mich errechnet sich da was im 20-sekunden-bereich per Frame, ja das passt etwa. Hängt natürlich auch etwas von der PC-CPU ab (bei mir ein AMD Ryzen 1600X).
thiloa hat geschrieben: Fr 11. Sep 2020, 20:15 Bezüglich der "Emulationsgenauigkeit" habe ich mich an die veröffentlichten Verilog Dateien von Parallax gehalten. Die Äquivalenz von meiner Kopie zu den Originaldateien konnte ich für die meisten Teilkomponenten (cog, cog_alu, cog_ctr, cog_vid, hub) mit dem Tool yosys formal verifizieren.

Ich hoffe nur, dass die Verilogdateien von Parallax auch wirklich ihrem Chip in Hardware entsprechen ;)

Nicht ganz - die PLLs sind in der Verilog-version digital nachgeschwurbelt (in Hardware nicht-deterministisch, siehe die RealRandom.spin die bei PropTool dabei ist und diesen Artikel: http://linusakesson.net/programming/pro ... llsync.php). Außerdem bin ich mir nicht sicher ob die schon genannte Zero-Flagge (oben außversehen Carry geschrieben...) von WRxxxx wirklich so im Verilog steht oder ob das ein reiner Hardware-Bug ist (der P1 ist noch von Hand gelayoutet worden, kann gut sein, dass sich dabei irgendwas komisches eingeschlichen hat, Siehe https://github.com/konimaru/modulity/issues/1)
thiloa hat geschrieben: Fr 11. Sep 2020, 20:15 Eventuell liegt der Geschwindigkeitsunterschied aber auch nur an C# (VM) im Vergleich zu C++?.
Ja, das wird wohl der Punkt sein. Ich hab mir schon öfter nen Kopf gemacht, wie man einen schnellen P1-Emulator zu Stande bringt. Für Das Spiel™ habe ich für den Logik-Code einen statischen Recompiler geschrieben (spezial-PASM (soweieso da XMM) -> C++ -> nativ) und Grafik/Sound-Code in sinnvollem C++ nachgebaut. Eine Art High-Level-Emulator also. Läuft selbst ohne Optimierung, mit sinnigkeitstest jedes Hub-Zugriffs und aktivem Profiler vielmals schneller als nötig. Geht aber natürlich nur für Programme, die gegen die spezielle pseudo-VM geschrieben sind (z.b. müssen potentielle Ziele dynamischer Sprünge annotiert sein...).

Genereller würde ein JIT-compiler sinn machen - voralldem wenn ein Cog, der gerade nicht taktgenau ausgeführt werden muss (Video und counter inaktiv, etc) allen code zwischen zwei Hub- oder I/O-Operationen am Stück ausführen kann. Aber auch bei taktgenauer Ausführung könnte was rauszuholen sein, wenn der Code nativ übersetzt ist.
thiloa
Beiträge: 37
Registriert: So 6. Okt 2019, 21:06

Re: Virtueller Hive

Beitrag von thiloa »

Durch einige Optimierungen konnte ich jetzt die Ausführungsgeschwindigkeit noch etwa um den Faktor 3 steigern, die Matrix Demo läuft jetzt mit 1,7 MHz.
Wuerfel_21 hat geschrieben: Fr 11. Sep 2020, 21:19 Außerdem bin ich mir nicht sicher ob die schon genannte Zero-Flagge (oben außversehen Carry geschrieben...) von WRxxxx wirklich so im Verilog steht oder ob das ein reiner Hardware-Bug ist
Das Zero Flag bei den WRxxx Operationen scheint wohl ein Hardwarebug zu sein. Konnte da jetzt nichts merkwürdiges im Verilog finden.

Das mit dem JIT Compiler werde ich evtl. demnächst erst einmal in der sehr einfachen Variante testen. Alle Register, die sehr selten geändert werden (Video/Counter Einstellungen, Cog running Flag...) könnten durch dynamisches neu kompilieren heraus optimiert und dadurch ein paar Sprünge eingespart werden.

Einen echten JIT Compiler, der noch zyklengenau ist, stelle ich mir nicht so leicht vor. Zum einen sind die Cogs (und typisch darauf laufender Code) schon stärker verzahnt, als z.B. Cores auf einem normalen PC. Zum anderen ist der gemeinsame Cog Ram für Code und Daten sowie der ganze selbst modifizierende Code nicht gerade JIT freundlich.
Benutzeravatar
PIC18F2550
Beiträge: 2831
Registriert: Fr 30. Sep 2011, 13:08

Re: Virtueller Hive

Beitrag von PIC18F2550 »

Es gibt keine Register zum Rauscompilieren Viele werden für andere Dinge missbraut.
Warum hältst du dich nicht einfach an das Handbuch, im Assemblerteil ist alles beschrieben.

Du solltest beachten das nach jeden einzelnen COG durchlauf die HUB Optionen neu ausweten musst bevor der nächste COG seinen durchlauf macht.

Hinter einigen Registern steken Hartware Funktion z. B. PLL mit 128Mhz.

Ohne diese Funktionen werden einige Programme nicht laufen.

Die 32Bit Opcode würde ich in die Funktionsblöcke zerlegen und danach entsprechend veratbeiten.

Als hauptschleife wäre eine mit Timer angebracht.
Gruß
PIC18F2550

drone265/278
Barbarus hic ergo sum, quia non intellegor ulli.
Ein Barbar bin ich hier, da ich von keinem verstanden werde.
ʎɐqǝ ıǝq ɹnʇɐʇsɐʇ ǝuıǝ ɹǝpǝıʍ ǝıu ǝɟnɐʞ ɥɔı ´uuɐɯ ɥo
thiloa
Beiträge: 37
Registriert: So 6. Okt 2019, 21:06

Re: Virtueller Hive

Beitrag von thiloa »

PIC18F2550 hat geschrieben: Fr 18. Sep 2020, 18:21 Es gibt keine Register zum Rauscompilieren Viele werden für andere Dinge missbraut.
Naja, wie häufig ändert denn ein durchschnittliches Programm z.B. das VCFG Register? Ich würde sagen eher nicht so häufig. Da kann man eventuell die Emulationsgeschwindigkeit schon nochmal steigern, wenn man Teile des Emulators dynamisch bei jeder VCFG Änderung rekompilieren lässt. Dieser Vorgang würde automatisch im Hintergrund ablaufen.

Meine letzter Post war da eventuell auch nicht so ganz klar formuliert. Mit "heraus optimieren" meinte ich nicht, dass das Register komplett aus dem Code entfernt wird. Es wird nur bei jeder Änderung des VCFG Registers eine neue optimierte Version des Propeller Interpreters erzeugt, auf dem der Code dann bis zur nächsten VCFG Änderung weiterläuft. Damit wird die Operation "VCFG ändern" sehr teuer (d.h. langsam), aber die anderen Instruktionen werden dadurch schneller, weil weniger Hostbefehle (x86) zur Abfrage des VCFG Registers erfordlich sind (und das wird ja jeden Takt gemacht). Die Simulation bleibt trotzdem zyklengenau und das Ergebnis zu 100% gleich.

Wenn ich auf diesem Emulator ein Programm laufen lassen würde, welches alle paar Takte das VCFG Register ändert, ist dieser Ansatz natürlich für die Geschwindigkeit eher schlecht, trotzdem bleibt das Ergebnis korrekt. Für alle anderen Fälle gewinne ich aber Performance. Kann man eventuell mit einem Zip Programm vergleichen, nur das hier nicht Speicher sondern Emulationszeit gepackt wird ;)
Bei den "großen" Emulatoren VirtualBox/VMWare/Qemu etc wird genau so etwas auch teilweise gemacht.
PIC18F2550 hat geschrieben: Fr 18. Sep 2020, 18:21 Warum hältst du dich nicht einfach an das Handbuch, im Assemblerteil ist alles beschrieben.
Bisher habe ich mich an die Verilog Dateien von Parallax gehalten, womit das im Handbuch beschriebene Verhalten enthalten sein sollte. Im Handbuch ist allerdings definitiv nicht alles beschrieben - es gibt undokumentiertes Verhalten im Propeller. Wuerfel_21 hat ja ein paar Dinge schon erwähnt.
PIC18F2550 hat geschrieben: Fr 18. Sep 2020, 18:21 Du solltest beachten das nach jeden einzelnen COG durchlauf die HUB Optionen neu ausweten musst bevor der nächste COG seinen durchlauf macht.
So läuft es bei meinem Emulator in etwa aktuell. Es hängen aber nicht alle Instruktionen vom Hub ab. Man könnte eventuell Ausführungsgeschwindigkeit gewinnen, wenn man kleine Sequenzen von PASM Code, der nicht vom Hub/Pins abhängt oder beeinflusst dynamisch durch optimierten Code auf der Host CPU ersetzt. Damit das noch exakt funktioniert, müssten dynamische Änderungen vom PASM Code (wie sie beim Propeller auch üblich sind, im Gegensatz zu typsichem x86 Code) hierbei berücksichtigt werden. Auch müsste man das irgendwie noch mit dem virtuellen Systemtakt mitzählen, damit die Cogs nicht auseinanderlaufen.
Ich habe mir über diesen Teil noch nicht so viele Gedanken gemacht und halte es auch für sehr aufwändig.
Benutzeravatar
PIC18F2550
Beiträge: 2831
Registriert: Fr 30. Sep 2011, 13:08

Re: Virtueller Hive

Beitrag von PIC18F2550 »

Du wiist einen sich selbst compilierenten Simulator bauen.

Na ja ein überspringen nicht genutzter Funktionen währe einfacher.

Da will ich mal warten und mir das Ergebnis ansehen.
Gruß
PIC18F2550

drone265/278
Barbarus hic ergo sum, quia non intellegor ulli.
Ein Barbar bin ich hier, da ich von keinem verstanden werde.
ʎɐqǝ ıǝq ɹnʇɐʇsɐʇ ǝuıǝ ɹǝpǝıʍ ǝıu ǝɟnɐʞ ɥɔı ´uuɐɯ ɥo
thiloa
Beiträge: 37
Registriert: So 6. Okt 2019, 21:06

Re: Virtueller Hive

Beitrag von thiloa »

Die Turbulence Demo läuft jetzt endlich auch, nachdem ich einen Fehler im I2C EEPROM Emulator beseitigt habe...

An der Geschwindigkeit hat sich leider noch nichts geändert.

turbulence-demo.png
Benutzeravatar
zille9
Beiträge: 399
Registriert: Do 4. Okt 2012, 21:56
Wohnort: Berlin

Re: Virtueller Hive

Beitrag von zille9 »

Ich bin begeistert, thiloa :DAUMENHOCH . Ein Hive-Emulator --- Ingoooooooo --- Drohne235 --- hast Du das schon gesehen?, das Kollektiv ist nicht tot !!!
Etwas ruhig ist es in den letzten Monaten (oder waren es Jahre?) schon um den Hive geworden, umso erfreulicher, wenn es doch noch einige aktive Drohnen hier im Forum gibt. Mach weiter so und poste deine Erfolge, bin mächtig gespannt, wie das Ergebnis aussieht.
Die ersten Versuche sind ja schon sehr vielversprechend. Ich sage jedenfalls Daumen hoch :DAUMENHOCH .
Computer lösen die Probleme, die man ohne sie gar nicht hätte!
Antworten