OpenSpin Compiler überarbeitet

[thiloa]

Hallo,

ich habe in der vergangenen Zeit mal den OpenSpin Compiler auf moderneres C++ überarbeitet.

Die unnötigen Restriktionen (Begrenzung der If/Case/Loop Blöcke, Ausdrucktiefe) sind jetzt behoben. Außerdem funktioniert die Entfernung unbenutzter Funktionen besser. Vorher gab es eine Restriktionen von 255 Funktionen vor der Optimierung. Diese Restriktion gilt jetzt nur noch nach der Optimierung bedingt durch den Spin Interpreter.

Außerdem gibt es jetzt einen HTML Ausgabemodus, mit dem man sich den Aufbau einer Objekt Binärdatei genau anschauen kann.

Prinzipiell lässt sich jetzt der Binärcode auch leichter optimieren, aber das habe ich noch nicht umgesetzt. Derzeit sollte die Binärausgabe exakt der von OpenSpin entsprechen. Das habe ich mit den OBEX Spin Files getestet.

Wer Interesse hat, kann gerne unter https://github.com/ThiloA/OpenSpin vorbeischauen, dort gibt es auch vorkompilierte Anwendungen.

[yeti]

                 


Hast Du eine Idee für einen handlichen (File-)Namen für Deinen Compiler?
Die alte und die Deine Variante (zumindestens ab und zu) konfliktfrei nebeneinadder nutzen wollen wird vermutlich keine so selten vorkommende Situation sein.

[yeti]

Prinzipiell lässt sich jetzt der Binärcode auch leichter optimieren, aber das habe ich noch nicht umgesetzt.

Schau dazu mal in das ByteCode-Backend von Spin2CPP (FlexSpin und Freunde) und/oder ping mal Würfel21 dazu an. Vielleicht ergeben sich Synergien.

[thiloa]

                 


Hast Du eine Idee für einen handlichen (File-)Namen für Deinen Compiler?
Die alte und die Deine Variante (zumindestens ab und zu) konfliktfrei nebeneinadder nutzen wollen wird vermutlich keine so selten vorkommende Situation sein.

Bisher erzeugen sie ja noch die gleiche Ergebnisse, meine Version nimmt nur mehr Spindateien an . Aber du hast recht, ein separater Name wäre schon gut. War da etwas einfallslos, bin für Vorschläge offen. Hatte es bisher intern manchmal nur OpenSpinFork genannt, aber naja

Ich habe jetzt übrigens mal die TriOS Dateien im Regnatix Ordner (system/regnatix/*.spin) mit bst und meiner openspin Variante übersetzt. Bei bst habe ich die "-O a" (alle Optimierungen) verwendet, bei OpenSpinFork nur -u.

Anbei die Ergebnisse (in Bytes der Binärdatei) welche mich durchaus positiv überrascht haben.

Code: Alles auswählen

Datei             BST   OpenSpinFork
admtest          8860           7560
beltest          7036           5548
charmap          2896           1220
eram             7612           6532
flash            7796           6136
fm               8608           7716
fterm            3312           1648
ftp              7696             NA
g0test           6576           5480
hplay            4636           3248
ipconfig         5224           3572
irc             14072          12764
keycode          2824           1296
man              3384           1776
m                4080           2700
perplex          7016             NA
ramtest          4896           3420
regime          10104           9584
rom              5008           3100
sfxtool          7296           5648
splay            3704           2236
sysconf          4872           3528
tapecut          4204           2728
time             6460           4780
wplay            3992           2620
yplay            3992           2504

Interessanterweise erzeugt BST trotz Optimierung und Entfernung unbenutzter Methoden fast immer deutlich größere Dateien als meine Variante, die außer der Entfernung unbenutzter Methoden sonst keinerlei Optimierungen durchführt.

Ich habe mal bei ein paar Dateien in das erzeugte Binary geschaut, und festgestellt, dass BST offenbar einige, aber nicht alle unbenutzten Methoden entfernt. Ist das normal so? Oder gibt es da noch irgendeine geheime Zusatzoption die ich vergessen haben? Das war sowohl bei bstc als auch in der bst IDE so. So ganz verstanden habe ich das noch nicht...

Bei "perplex" und "ftp" gibt es mit OpenSpin Probleme, das muss ich mir nochmal anschauen.

Viele Grüße
Thilo

[yeti]

Aber du hast recht, ein separater Name wäre schon gut. War da etwas einfallslos, bin für Vorschläge offen. Hatte es bisher intern manchmal nur OpenSpinFork genannt, aber naja

Ich hab das Binärchen bei mir erstmal 𝚘𝚙𝚎𝚗𝚜𝚙𝚒𝚗-𝚝𝚊 getauft. Das war auch nicht grad hyperkreativ. Solange beide Versionen sehr nahe Verwandte sind, würde ich eine Unterscheidung am Ende des Namens bevorzugen. 𝚘𝚙𝚎𝚗𝚜𝚙𝚒𝚗[TAB] würde dann alle nahen Verwandten anbieten, was der Generation [TAB]süchtig sehr entgegenkommen würde.

Ich habe mal bei ein paar Dateien in das erzeugte Binary geschaut, und festgestellt, dass BST offenbar einige, aber nicht alle unbenutzten Methoden entfernt. Ist das normal so? Oder gibt es da noch irgendeine geheime Zusatzoption die ich vergessen haben? Das war sowohl bei bstc als auch in der bst IDE so. So ganz verstanden habe ich das noch nicht...

Ich hab immer nur brav exakt die Optionen benutzt, die in Chefdrohne's Bauskript stehen. BSTC hinterfragen, wo dessen Source nichtmal verfügbar ist, ist vermutlich Lebenszeitverschwendung.

Bei "perplex" und "ftp" gibt es mit OpenSpin Probleme, das muss ich mir nochmal anschauen.

Ich hab auf die schnelle versucht das Bauen auf 𝚘𝚙𝚎𝚗𝚜𝚙𝚒𝚗-𝚝𝚊 umzustricken, aber meine heutige Aufmerksamkeitsspanne reichte einfach nicht dafür.

[thiloa]

Ich hab immer nur brav exakt die Optionen benutzt, die in Chefdrohne's Bauskript stehen. BSTC hinterfragen, wo dessen Source nichtmal verfügbar ist, ist vermutlich Lebenszeitverschwendung.

Nun zum Lebenszeit verschwenden sind wir ja hier Habs jetzt herausgefunden. Folgendes Minimalbeispiel

Code: Alles auswählen

PUB F1
PUB F2
  F3
PUB F3

BSTC entfernt hier richtigerweise zwar F2, bindet aber F3 unnötigerweise ein. Es werden die Methoden offenbar nicht rekursiv durchgegangen, jede Methode die referenziert wird (auch wenn ihrerseits in einer unbenutzten Methode) scheint eingebunden zu werden. OpenSpin (bereits das Original) entfernt sowohl F2 als auch F3.

Bei "perplex" und "ftp" gibt es mit OpenSpin Probleme, das muss ich mir nochmal anschauen.

Ich hab auf die schnelle versucht das Bauen auf 𝚘𝚙𝚎𝚗𝚜𝚙𝚒𝚗-𝚝𝚊 umzustricken, aber meine heutige Aufmerksamkeitsspanne reichte einfach nicht dafür.

Das "perplex.spin" habe ich hinbekommen. Schuld war Zeile 266:

Code: Alles auswählen

PRI plx_game|dev,i

"DEV" ist ein reserviertes Schlüsselwort für einen Block (sowas wie OBJ, PUB usw.) Scheint aber undokumentiert zu sein. Habe die Variable device genannt, dann klappt es. Aber die Fehlermeldung sollte ich mal anpassen, ist irgendwie wenig aussagekräftig. Muss mal schauen, ob dieser Block in OBEX überhaupt mal benutzt wird. Da konnte man irgendwelche Archivdateien einbinden, mit denen aber auch im Compiler offenbar nicht wirklich etwas gemacht wird... Der Zweck des Blockes ist mir nicht so ganz klar geworden.

"ftp.spin" scheint komplizierter zu sein

Code: Alles auswählen

i := sendStr(string("CWD ")) || sendStr(@defdir) || sendStr(string(13,10))

Ich bin mir nicht sicher was gewollt, ist, aber || gibt es in Spin doch eigentlich nicht wie in C++ als ODER, sondern m.W. nur als unäre ABS Operation. Laut BST Manual gibt es das auch nicht als Erweiterung. BST scheint das auch m.E. falsch zu übersetzten, es sollte eher einen Fehler ausgeben. Aus

Code: Alles auswählen

a := b || c

wird dann sowas wie

Code: Alles auswählen

push b
push c
absop
write a

Da müsste es eigentlich Probleme mit dem Stack geben, da b noch drauf liegt. Bin mir aber nicht ganz sicher. Was sollte denn eigentlich mit dem Code erreicht werden? Von der Logik her würde ich sagen, es sollen vermutlich alle sendStr Operationen nacheinander ausgeführt werden. Und wenn eine der Operation fehlschlägt, dann i:=TRUE setzen?

[PIC18F2550]

Ich würde mir ein besseren Assembler für den P1 & P2 wünschen.
Spinn und C sind mir etwas egal.

[yeti]

Ich würde mir ein besseren Assembler für den P1 & P2 wünschen.

Dafr lohnt sich vermultich einen eigener Thread.
—▷ viewtopic.php?f=12&t=1630

[Wuerfel_21]

Hinsichtilich des BSTC-Vergleichs oben, scho mal mit flexspin's bytecode-modus verglichen? Für den stehe ich mit meinem Namen.

Tests gegen OpenSpin und BSTC von damals(tm): https://forums.parallax.com/discussion/ ... out#latest

tl;dr; flexspin bytecode zerstört BSTC auf allen Ebenen.

(mittlerweile kann man auch "flexspin -1bc" schreiben statt "flexspin --interp=rom"...)

Der echte clou sind natürlich die extra-features. Nicht alles, was mit dem "echten" ASM-kompiler geht, geht auch in bytecode, aber u.a. möglich:
- abstract object / Objektpointer
- bis zu 4 return-Variablen (etwas langsam da workaround) und multi-assign (aka "x,y := 10,20")
- Einige Spin2-features (Ternär-operator, byte-Arrays in lokalen Variablen, @"string", postset (backslash), etc)
- Begrenzter support für die Spin2, C und BASIC frontends

Mehr dazu hier: https://github.com/totalspectrum/spin2c ... oc/spin.md
Wobei die doku um bytecode tatsächlich etwas mangelt.

[thiloa]

Hinsichtilich des BSTC-Vergleichs oben, scho mal mit flexspin's bytecode-modus verglichen? Für den stehe ich mit meinem Namen.

Tests gegen OpenSpin und BSTC von damals(tm): https://forums.parallax.com/discussion/ ... out#latest

Hallo,

nein, das habe ich noch nicht. Genau genommen sollte sich da auch bisher noch nichts zu deinem Test geändert haben, da alle Dateien die vorher schon mit OpenSpin kompilierten, mit meinem Fork byteweise gleiche Ausgabe erzeugen (sollten). Lediglich Dateien, die vorher aufgrund zu vieler unbenutzter Methoden / zu tiefer Verschachtelung von Ifs Case usw. nicht funktioniert haben, sollten jetzt ggf compilieren.

Wenn ich ein paar neue Optimierungen eingebaut habe, werde ich mal einen Vergleich durchführen.