HIVE-Project

yeti hat geschrieben: ↑Di 14. Mär 2023, 20:20
Wer noch nicht mit FlexSPIN, -BASIC und -C im Bytecode-Modus gespielt hat sollte sich das mal ansehen. OpenSpin könnte obsolet werden, zumindest solange kein OpenSpin-fehlerkompatibler Compiler benötigt wird.

Um was für OpenSpin-spezifische Eigenheiten handelt es sich denn? Wenn irgendwas in flexspin nicht passt, wird es passend gemacht (fast alle Eigenheiten des Original-PropellerTool-Kompilers sollten unterstützt sein, besonders im BC-Modus. Das einzige was nicht funktionieren sollte und kein Fehler ist, ist Code der sich selbst modifiziert (gezwungenermaßen mit festen offsets in PBASE).

Man beachte auch die Spin2-ismen, die auch für Spin1/P1 unterstützt sind. z.B. die Möglichkeit, Konstanten in Unterobjekten zu überschreiben.

Bloß nich...

Im Umfeld des Versuches TriOS mit OpenSpin zu bauen tauchten Unterschiuede zwischen OpenSpin und BSTC auf, die man nun wirklich nicht in FlexSpin haben will.

Fehlerkompatibel sollte meinen "kompiliert gewisse Dinge gar nicht". Z.B. zuviele Funktionen, zuviele IF/ELSE/...

BSTC konnte das teils umschiffen weil erst Unbenutztes rausgeschmissen wurde und OpenSpin sich erst weigerte und danach optimiert hätte (wenn ich das richtig verstand).

FlexSpin hat eigentlich keine Limits dergleichen. Nicht benutze Funktionen werden gar nicht erst kompiliert. Und Konstrukte in der Funktion sollten sich unendlich verschachteln lassen (naja, irgendwann läuft der Systemstack dir über... 8MB auf Linux, nur 1MB auf Windows...)

BSTC hat teils... interessante Fehler. Wer versuchen würde Spin Hexagon (was zwar auf flexspin LLM gedacht ist..) mit BSTC zu kompilieren, würde nicht glücklich werden (aber auch nicht mit Homespun). Siehe hier: https://forums.parallax.com/discussion/ ... r-shootout

Und BST(C) gibt's nur binär und wird irgendwann auf keinem aktuellen OS mehr laufen. Diesen Mist hab ich mit anderen Compilern bzw Microcontrollern schon hinter mir, weil manch Projekt sich zu sehr an eine bestimmte GCC-Version kettete.

Spatz geht anders.

Och ja, und XMM... Das wär was. Auf P2-Seite hätte das auch vertretbare Performance dank Streamer-DMA. Nicht sicher wie das wohl am besten zu implementieren ist. Ich glaube die implementation in GCC cache-t einfach gleich große Blöcke und führt sie aus. Und ich glaube ohne FCACHE, da das ja nicht einfach so aufzuteilen ist. P2 ist ja kein reines RISC und hat diese Probleme auch von Haus aus (liebe grüße von AUGS und SETQ. Lässt sich vielleicht lösen, wenn man diese Konstrukte alle auf 64-bit alignt). Und einzelne kleine Transfers leiden eher unter Latenz... Andererseits ist mein 68000-Emulator ja eigentlich auch nur XMM auf Umwegen. Und der läuft auch noch gut, wenn er (siehe NeoYume-Spaghetti) nur indirekt an den Bus kann und evtl eine Weile warten muss, bis der andere Cog den Interrupt wahrnimmt. Da werden 16 Instruktionswörter (=32 byte) gequeuet, wann immer der PC den aktuellen Bereich verlässt. Und genau von da an. Hat den Nachteil, dass man sich mit den ollen DRAM-Zeilen rumschlagen muss, da der Bereich ja über eine Zeilengrenze gehen könnte.

---------8<-----{20230812-1633-UTC}----->8----------

Ich seh PSRAM in SPIN2CPPs Changelog erwhähnt...

Verpaß ich Nur-P1-Benutzer da grad bahnbrechende Neuerungen oder ist das nur für P2-Leute interessant?

---------8<-----{20230812-1802-UTC}----->8----------
...also wohl nur für die P2-Fraktion.

---------8<-----{Wohl kein Happy-End.}----->8----------

Is nur für ramdisk als dateisystem, keine sorge.