OpenSpin - Open source Spin/PASM compiler in C/C++

[yeti]

OpenSpin

Es tut sich was: Open source Spin/PASM compiler in C/C++
Bei GitHub: https://github.com/parallaxinc/OpenSpin

Bald in den Sedimenten der Geschichte versunken:
Bei Goochl: http://code.google.com/p/open-source-spin-compiler/
(... bitte Bidding farewell to Google Code lesen.)

(((Altes Beispiel entfernt)))
(((Neues Beispiel entfernt)))

Mittlerweile sollte sich rumgesprochen haben wie man OpenSpin benutzt... der Threadstart kann also nun zur Downloadseite degradieren...

R || 0 Ohm

:P

----------8<----------

Edit 20160910: Nachschlag (1.00.78-4-gfe4797b für "cubietruck-armbian-jessie").
Edit 20160606: Update der Attachments (1.00.78-4-gfe4797b ist 1.00.80).
Edit 20151109: Anklickbares "R || 0 Ohm".

[yeti]

I have updated the project in google code to version r25. It now has CompileDoc translated from x86 to C/C++. This means the translation is complete.
I added a -d option to spin.exe that will dump out the results of CompileDoc (it's the same is documentation mode in the Prop Tool).

Now it's just any bugs that our found, and then on to new features and changes.

Mittlerweile ist's gar schon r26...
Bitte ran an die Tasten!
Testen, quälen, stressen, foltern, testen, quälen, stressen, foltern, testen, quälen, stressen, foltern und dies bitte reichlichST!

Ich hoffe es werden erstmal die Bugs erschlagen bevor das Teil totgefeatured wird...

Bisher hat Roy nicht knurrig auf Meldungen per Privat-Nachricht (statt öffentlich via Forum) reagiert; dieser Weg ist vielleicht für den Einen und/oder Anderen von geringerer Hemmschwelle... er wird schon Laut geben, wenn er es dann irgendwann anders wünscht...

[yeti]

Södele...
Ich hab das Teil mal statisch gelinkt...

Code: Alles auswählen

(yeti@destiny:4)~/wrk/tmp$ ls -l spin
-rwxr-xr-x 1 yeti yeti 647456 26. Jan 17:48 spin
(yeti@destiny:4)~/wrk/tmp$ ldd spin
        not a dynamic executable
(yeti@destiny:4)~/wrk/tmp$ ./spin -?
Propeller Spin/PASM Compiler (c)2012 Parallax Inc. DBA Parallax Semiconductor.
Compiled on Jan 26 2012
usage: spin
         [ -I <path> ]     add a directory to the include path
         [ -c ]            output only DAT sections (not implemented yet)
         [ -d ]            dump out doc mode
         [ -q ]            quiet mode (suppress banner and non-error text)
         [ -v ]            verbose output
         <name.spin>       spin file to compile

...es sollte also problemlos in den verschiedensten 32-bittigen Derivaten linuxbasierter Betriebssysteme laufen.

Ich betreibe hier alle Kisten mit 32-bittigem Debian-6.0.x oder NetBSD-5.1.x, 64-bittige Binaries schüttle ich also nicht mal eben aus'm Ärmel...

----------8<----------
Edit 20120127: spin-*.zip wird nun im threadstartenden Beitrag angebäppt und so es sinnig scheint gelegentlich geupdatet. Ich hab sogar gefunden wie man das nun überflüssige File löscht... \o/

[TuxFan]

Na, dann werd ich mal...........
Gruß
TuxFan

[TuxFan]

So, erstes Programm compiliert und erstes Manko festgestellt : Beschränkung auf 16 elseif's
Anderes Programm compiliert, gut das geht fix, aber keine Beschleunigung bei der Ausführung. Also .binary wie gehabt.
Worin soll jetzt der Vorteil gegenüber BST sein, nur die Quelloffenheit ?

Gruß
TuxFan

[yeti]

So, erstes Programm compiliert und erstes Manko festgestellt : Beschränkung auf 16 elseif's

Gemaaaaaach...
Es hat ja gerade erst die Beta erreicht...

Anderes Programm compiliert, gut das geht fix, aber keine Beschleunigung bei der Ausführung. Also .binary wie gehabt.

So muß das auch erstmal sein: Selber Code rein, selbes Binary raus...

Erweiterungen werden aber schon heftig diskutiert... jenseits des großen Tümpels...

Worin soll jetzt der Vorteil gegenüber BST sein, nur die Quelloffenheit ?

Nur?

Nur?!?

Nur?!?!?

Nur?!?!?!?!

Ich bin zutiefst schockiert!

Spin hat ohne quelloffenen Compiler einfach keine Zukunft...

...ok... mit quelloffenem Compiler wahrscheinlich trotzdem nicht...

...und...

BSTC ist technisch geseh'n derzeit noch weiter aber eben nicht quelloffen. Wenn Brad schlecht träumt und dann garnix mehr tut (hat er das nicht längst?) ist BSTC bald nimmer auf zeitgemäßen Libraries lauffähig. Dann kannst Du entweder ein aktuelles Betriebssystem oder BSTC haben. Obwohl am featurereichsten hab ich so jedesmal ein schlechtes Gefühl im Bauch wenn ich Code produziere der BSTC voraussetzt.

Homespun ist nicht so weit wie BSTC, hat gegenüber der Original-IDE aber #ifdef und Co und läuft im .NET- bzw Mono-Kondom notfalls auch auf ARM usw... aber auch nicht quelloffen...
Edit@20160527: Homespun ist mittlerweile quelloffen.

Die Original-IDE halte ich schlicht für unzeitgemäß was fehlende Optimierung und #-Zeuchs angeht... außerdem gibt's die nicht für die U-Nixen... und quelloffen isse schonmal garnich...

Sphinxcompiler ist wohl von den Features fast gleichauf mit der Original-Soft, aber wer benutzt das schon? Zum Trost gibt's aber die Quellen...

[TuxFan]

Moin moin!
Im Moment bin ich mir über keines der ganzen Compilerprojekte so richtig im klaren und weiß wirklich nicht, worin man seine Zeit investieren soll. In Richtung PropBasic (One man band) hab ich genug Zeit vertrödelt. Fing eigentlich vielversprechend an (ist wirklich verdammt schnell), dann gab es wohl Probleme mit der Integration in BST (One man band) und ist nun zu einer professionellen IDE (Viewport) abgewandert . Homespun sieht mir auch nach one man band aus, dazu nicht quelloffen, wenn der Bearbeiter umfällt.......... . Der c/c++ compiler auf Debian sieht schon besser aus, bloß gibt es Compilier-Probleme mit Systemen, die nicht Debian heißen . C hat mir persönlich noch nie gefallen..... . Spin selber finde ich garnicht mal so schlecht. Was ich aber nicht verstehe ist Parallax selber, wenn man vorher eine Basic-Briefmarke hat und dann plötzlich eine ganz andere Sprache entwickelt.
Ich weiß es nicht......
Zum Spin/PASM-compiler fehlt im Moment auch ein Lader. Dafür muß man doch noch BST anschmeißen oder hab ich was übersehen.....
Ich konzentriere mich jetzt erst mal auf PASM und bringe meine Props ans laufen und warte den ganzen Rummel um neue IDE, Compiler usw. erst mal ab.

Wie sieht es mit Eclipse als IDE aus, ist zwar nicht quelloffen, man kann aber eigene Compiler usw. anhängen ?

Gruß
TuxFan

[yeti]

Der c/c++ compiler auf Debian sieht schon besser aus, bloß gibt es Compilier-Probleme mit Systemen, die nicht Debian heißen .

Nöööö...
Andere benutzen PropGCC unter Windows und ich denke ich bekomme es auch unter anderen Unixen gebaut...
PropGCC halte ich für zukunftssicher...

Zum Spin/PASM-compiler fehlt im Moment auch ein Lader. Dafür muß man doch noch BST anschmeißen oder hab ich was übersehen.....

Es gibt einen Propellerlader in Python, einen in Pascal, einer kommt mit Catalina-C, im PropGCC-Projekt steckt ein Lader und BSTL hast Du ja selbst erwähnt... und vielleicht hab ich sogar noch welche übersehen...

Ich konzentriere mich jetzt erst mal auf PASM und bringe meine Props ans laufen und warte den ganzen Rummel um neue IDE, Compiler usw. erst mal ab.

PASM ist sicher 'ne gute Idee...

Wie sieht es mit Eclipse als IDE aus, ist zwar nicht quelloffen, man kann aber eigene Compiler usw. anhängen ?

Solchen Vollfettschweinkram konsumiere ich nicht, dazu mußt Du Andere befragen...

[hoeppie]

Wie sieht es mit Eclipse als IDE aus, ist zwar nicht quelloffen, man kann aber eigene Compiler usw. anhängen ?

Nicht Quelloffen?
Was meinste da genau?
SWT ist offen und der Rest von eclipse ist in Java gebaut?
http://www.eclipse.org/swt/
und der Source:
Für 4.X
http://download.eclipse.org/eclipse/downloads/
und 3.X
http://download.eclipse.org/eclipse/dow ... ipse3x.php

gruß Höp

[TuxFan]

Nicht Quelloffen?
Was meinste da genau?
SWT ist offen und der Rest von eclipse ist in Java gebaut?.....

Ach, kuck an, soooooooooooo lange hab ich da schon nicht mehr richtig hingeschaut....
Gruß
TuxFan