www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Compiler fuer Spin (Parallax Propeller), Interesse?


Autor: Michael G. (linuxgeek) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Michael G. (linuxgeek) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Michael G. (linuxgeek) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Arc Net (arc)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
http://imagecraft.wordpress.com/2008/08/27/paralla...

> 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/

Autor: Michael G. (linuxgeek) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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:
nxt    rdlong  instr,pc
       add     pc,#4
instr  nop                ' placeholder!
       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

Autor: Michael G. (linuxgeek) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.
  dira[3] := 1     
  repeat
    !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.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.