Hi Forum, ich habe Eure Diskussionen um den Propeller verfolgt. Ich spiele jetzt seit ein paar Tagen auch rum mit dem Teil und muss sagen dass ich ihn "erfrischend anders" finde ;) Einer der Hauptkritikpunkte war ja, dass Spin zur Laufzeit interpretiert wird und somit gigantische ca. 1000 Zyklen pro Hochspracheninstruktion benoetigt, was eine Menge der Leistung des Propellers verheizt. Persoenlich finde ich Spin allerdings garnicht mal so verkehrt. Jetzt ist Spin im Prinzip eine recht einfache Sprache, fuer die man sicher mit vertretbarem Aufwand einen Compiler schreiben koennte, zumal der Assembler ja mit Spin im Hinterkopf entwickelt wurde, so dass die Code-Erzeugung relativ straight-forward passieren koennte. Den Faktor 10 sollte man ohne Groesseres (also ohne hardcore-Optimierung) an Geschwindigkeit herausholen koennen, moeglicherweise sogar mehr (mit Optimierung auf jeden Fall mehr). Ich frag nur mal so in den Raum: Wie gross waere denn das Interesse an sowas? Leider ist der bootloader undokumentiert, aber wenn man ein Binaerabbild erstellt hat koennte man es ja ueber das standard-tool in den Propeller laden. Etwas umstaendlich aber irgendwann kann man ja auch mal ueber eine entsprechende GUI nachdenken, was es vereinfachen wuerde. Ausserdem waeren dann endlich mal freie (auch Linux)-Tools verfuegbar. Oder ist das Interesse am Propeller generell so klein dass sich der Aufwand nicht lohnt? Was meint Ihr? Um sowas gut vorantreiben zu koennen wird man sicherlich irgendwann Helfer brauchen, vor allem wenn man dann auch noch eine IDE dazu entwickeln will. Der grosse Vorteil an einem Spin-Compiler waere natuerlich, dass man vorhandenen Code (auch die libraries usw.) problemlos weiterbenutzen koennte und nicht wieder alles neu schreiben muss, nur um die Vorzuege eines Compilers nutzen zu koennen. Gruss, Michael P.S. Ich bitte die "gibt es doch schon" und "braucht doch keiner"-Trolle diesmal etwas Zurueckhaltung zu ueben. Vielleicht wird das ja mal kein Krieg sondern eine sinnvolle Diskussion.
Was wäre denn die Zielsprache eines solchen Compilers? Direkt ausgeführter Maschinencode ergibt nur begrenzt Sinn, denn der Propeller kann den nur im kleinen COG-Speicher direkt ausführen. Und zentral gespeichert ist er ziemlich raumgreifend, d.h. benötigt erheblich mehr Platz als interpretierter Zwischencode.
Hm... das is schon nen bissel bloed. Es gibt ja in Zwischenzeit einen C-Compiler, da haben die das Problem irgendwie geloest. Muesste man sich mal schlau machen. Vielleicht ist es aber sinnvoll einfach mal auf die naechste Propeller-Variante zu warten, die duerfte speichermaeszig deutlich besser ausgestattet sein. Wenn sie denn kommt :D
Es gibt was: http://propeller.wikispaces.com/LMM+AiChip+Industries >The LmmVm allows to up to 8k longs of code or data and allows access to >cog-based registers for fast run-time data storage.
http://imagecraft.wordpress.com/2008/08/27/parallax-propeller-and-the-propeller-c-compiler/ > Einer der Hauptkritikpunkte war ja, dass > Spin zur Laufzeit interpretiert wird und somit gigantische ca. 1000 > Zyklen pro Hochspracheninstruktion benoetigt, was eine Menge der > Leistung des Propellers verheizt. Persoenlich finde ich Spin allerdings > garnicht mal so verkehrt. s.o. > Leider ist der bootloader undokumentiert, aber wenn man ein > Binaerabbild erstellt hat koennte man es ja ueber das standard-tool in > den Propeller laden. http://obex.parallax.com/objects/61/
Das Grundprinzip vom LMM ist, dass der Code vom global memory in den COG
kopiert wird und dort ausgefuehrt wird. Nachteil ist halt dass der
Ansatz nicht mehr ganz so schnell wie nativer Assembler ist. Das
Code-Groessen-Problem hat man damit allerdings geloest. Es gibt sogar
nen Ansatz wo noch mehr Code aus nem externen Speicher geladen werden
kann (wird wahrscheinlich nicht besonders schnell sein). Uebrigens wird
das LMM (Large Memory Model) auch vom offiziellen C-Compiler verwendet.
Somit waere man hier zumindest nicht brachial im Nachteil was die
Geschwindigkeit angeht.
>The basic virtual machine consists of just 4 lines of assembler:1 | nxt rdlong instr,pc |
2 | add pc,#4 |
3 | instr nop ' placeholder! |
4 | jmp nxt |
>As can be seen, at nxt an instruction pointed the by the Program Counter >(pc) is copied to Cog memory at instr (replacing the nop). Then after >incrementing the program counter to the next long, the instruction is >executed. This loop takes 32 cycles, and so is 8 times slower than native >assembler for executing code, but several times faster than spin. However >the loop can be unrolled to make it faster - Bill suggests unrolling 4 > times to get it just 5 times slower than native assembler. Uebrigens ganz lustig fuer was die $200 haben wollen: http://propeller.wikispaces.com/Programming+in+C
Arc: Hab beim Stoebern schon gefunden dass der Bootloader und Interpreter-Code released wurden, thx anyway ;) Das ist jetzt allerdings nicht so enorm wichtig fuer einen Compiler, sondern nur fuer das Programming-Tool. Bei einem Systemtakt von 80MHz kommen wir auf eine Taktdauer von 12.5ns. Wenn der Propeller ca. 80000 Spin-Instruktionen pro Sekunde ausfuehrt, sind das 8000 Systemtakte pro Instruktion oder ca. 100us. Ganz schoen happig. Das kommt aber wirklich hin.
1 | dira[3] := 1 |
2 | repeat
|
3 | !outa[3] |
Das erzeugt bei 80MHz Systemtakt ein Signal von ca. 43KHz an Pin 3, was fuer einen Schleifendurchlauf etwa 1860 Takte (~ 23us) entspricht. Da wird ja noch nichts gerechnet sondern einfach nur ein Register geaendert. Hub-Operationen sind auch nicht noetig da die COGs direkt an die I/Os angeschlossen sind.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.