SimpleIDE-Programme schneller wie von Propeller Tool v1.3.2

[funkheld]

Hallo, guten Tag.

Sind SimpleIDE-Programme schneller im Propeller wie die vom Propeller Tool v1.3.2 ?

Ich kenne das von der C-Control(AVR32) her, das es dort ein Basic gibt und C-control-C, aber die Programme sprechen mit dem fertigen Compilat beide den eingebauten Interpreter im AVR32 an.

Der Propeller hat ja auch irgendwie ein Interpreter drin, werden auch beide Compilate gleich schnell behandelt und der C-Compiler nur eine Schau ist?

Gruss

[nubok]

Mit dem Propeller Tool kannst du sowohl Spin- als auch Assembler-Programme erstellen, während SimpleIDE (ich habe damit bislang noch nicht gearbeitet) C verwendet, welche vom Compiler in Maschinensprache (Maschinen-Repräsentation des Assembler-Codes) übersetzt wird.

Spin ist ca. 10 mal langsamer als Asssembler (Quelle leider vergessen).

Typischerweise kann bei vielen Microcontrollern C nicht mit handoptimiertem Assembler mithalten, aber schneller als Spin sollte es allemal sein.

Daher:

Assembler (z. B. Propeller Tool): am schnellsten
C (z. B. mit SimpleIDE): langsamer
Spin (z. B. Propeller Tool): am langsamsten

[drohne235]

Blanker Maschinencode ist ca. 60..100 mal schneller als Spin. SimpleIDE/C kann aber keinen blanken Maschinencode für den Propeller erzeugen, da dieser Maschinencode nur im Cog-RAM läuft, und der Cog-RAM nur winzig klein (512 Befehle) ist. Also wird dieses C (Vermutung) wahrscheinlich ein LMM verwenden um im Hub-RAM zu laufen. Eine LMM "kostet" aber Geschwindigkeit, was weniger an der Optimierung als am grundlegenden Prinzip liegt.

Eine interessante Frage, welche es zu ergründen gilt...

[PIC18F2550]

Das stimmt.

Den Unterschied habe ich bei meinem Rack ganz schön zu spüren bekommen.
Die Ausführung einer Routine benötigte nur die Zeit zwischen der Abarbeitung zweier Befehle in SPIN
Das wollte ich erst auch nicht glauben.
Und habe mit Prüfroutinen rumgebastelt.
Also wenn du ordentlich Dampf machen willst vergiss SPIN und C denn beide sind nur Runtimemodule in LMM Format.
Das beste du versuchst dein Programm in den 8 COG's unter zu bringen so wie ich.

[yeti]

Blanker Maschinencode ist ca. 60..100 mal schneller als Spin. SimpleIDE/C kann aber keinen blanken Maschinencode für den Propeller erzeugen, da dieser Maschinencode nur im Cog-RAM läuft, und der Cog-RAM nur winzig klein (512 Befehle) ist.

Falsch!
PropGCC kann "nativen" Code für die Cogs generieren.

Also wird dieses C (Vermutung) wahrscheinlich ein LMM verwenden um im Hub-RAM zu laufen.

Auch wahr!
PropGCC kann LMM, CMM und XMM-Varianten.

LMM ist Prop-Assembler in LMM-Schleifen wohl direkt vergleichbar, CMM ist ein optimierter (komprimierter/"compressed", daher das C vor'm MM) Befehlssatz, der angäblich Spin am ähnlichsten ist von Geschwindigleit und Codeeffizienz (irgendwo gelesen, nicht selber ausprobiert). XMM ist sozusagen LMM auf externem Speicher und damit in meinen Augen der interressanteste Aspekt an PropGCC: Man durchbricht damit mit verschiednen Speichermodellen die 32k-Barriere für die Codegröße, die der Hub darstellt. Wiederum auf Kosten der Geschwindigkeit. Klar! Dabei sind zwei Modelle zu unterscheiden: Nur Code im XMM (Daten und Stacks usw bleiben im Hub) oder Alles im XMM...

Eine LMM "kostet" aber Geschwindigkeit, was weniger an der Optimierung als am grundlegenden Prinzip liegt.

Aber was ist denn Spin-Code? Letztlich auch "nur" eine VM oder eine Art LMM-Code...
Ein Fairer Vergleich muß Spin-Compilate mit LMM- oder CMM-Code von PropGCC vergleichen und zu C->Cog-Code bietet Spin kein Äquivalent außer selber die Hände in Assembler quirlen lassen...

...und irgendwie kann man bestimmt auch Cog-Code und anderen Code mischen, denn irgendwie müssen ja die "Treiber" in die Cogs kommen, die dem LMM-Code manch zeitkritische Arbeit abnehmen... aber so tief bin ich noch nicht mit meinem Wühlen in den PropGCC-Tiefen...

--> http://propgcc.googlecode.com/hg/doc/Memory.html

[drohne235]

PropGCC kann "nativen" Code für die Cogs generieren.

War mir neu. Aber ob das sinnvoll ist, wage ich zu bezweifeln. Ich meine, einfach mal so aus dem Bauch raus: Wenn es richtig schnell sein soll, dann würde ich PASM direkt verwenden ohne den Umweg über C. Aber ich lasse mich da gern eines besseren belehren. Der Prüfstein wäre mal ein VGA Treiber in C geschrieben - wenn das geht wäre das brauchbar...

Aber was ist denn Spin-Code? Letztlich auch "nur" eine VM oder eine Art LMM-Code...

Jo, die Grenzen sind da fließend.

Ein Fairer Vergleich muß Spin-Compilate mit LMM- oder CMM-Code von PropGCC vergleichen und zu C->Cog-Code bietet Spin kein Äquivalent außer selber die Hände in Assembler quirlen lassen...

Ist CMM ein Bytecode?

Bei LMM muss man in jedem Fall beachten, dass jeder Befehl wenigstens (Wie groß ist ein JMP/CALL im LMM Code?) einen Long verbraucht im Gegensatz zum schlanken Bytecode von Spin. Nicht ganz unerheblich bei dem knappen Speicher im Prop.

außer selber die Hände in Assembler quirlen lassen...

Blankes Metall - ist doch wunderbar!

[yeti]

PropGCC kann "nativen" Code für die Cogs generieren.

War mir neu. Aber ob das sinnvoll ist, wage ich zu bezweifeln. Ich meine, einfach mal so aus dem Bauch raus: Wenn es richtig schnell sein soll, dann würde ich PASM direkt verwenden ohne den Umweg über C. Aber ich lasse mich da gern eines besseren belehren.

Mit einem gut optimierenden C-Compiler erreicht man sicher höhere Geschwindigkeiten als mit VMs. Mein Fixpunktarrithmetik-Apfelmännchen in Lattice-C auf dem Atari-ST ließ sich nur ca um Faktor 2 durch übersetzen in Assembler beschleunigen und Lattice-C war nicht grad der Optimierungs-King.

In Sachen Einarbeitungsdauer zu Codegeschwindigkeit ist C meiner Meinung nach immer einen Blick wert.

Zudem kann man ja immer noch nach etwas Profiling die relevanten Stellen in Assembler daneben legen (#ifdef usw...).

Niemand hat die Absicht, ein Assembler-in-C-Einbettungsverbot zu erlassen.

Der Prüfstein wäre mal ein VGA Treiber in C geschrieben - wenn das geht wäre das brauchbar...

Es wird sicher nicht an der "VGA-Treiber in C ist machbar"-Frage entschieden werden, ob PropGCC eingestampft oder weiter entwickelt wird.

Zudem sind brauchbare VGA-Treiber für Spin auch nicht in Spin geschrieben. Die Assembleranteile, die man bereitwillig vermeindlichen Spin-Objekten für VGA-Ausgabe zubilligt, muß man selbstverfreilich auch C-Code zubilligen.

Aber trotz Allem bin ich zuversichtlich, daß wenn sich die bekannten Propeller-Zauberer auf PropGCC stürzen, uns noch manchmal der Unterkiefer runterklappen wird... bei weniger Assembleranteil als erwartet...

Ist CMM ein Bytecode?

The CMM Instruction Set
-----------------------
The compressed forms of instructions are byte oriented, and can be
read from any byte boundary. They are of variable length. The first
byte specifies the instruction type and (usually) the destination
register; following bytes fill in the rest of the instruction.

(((...hier geht's weiter...)))

[drohne235]

Zudem sind brauchbare VGA-Treiber für Spin auch nicht in Spin geschrieben. Die Assembleranteile, die man bereitwillig vermeindlichen Spin-Objekten für VGA-Ausgabe zubilligt, muß man selbstverfreilich auch C-Code zubilligen.

Naja, ich bezog mich da mehr auf deine Aussage, dass PropGCC auch nativen Code für Cogs generieren kann. Unter nativem Code verstehe ich Maschinencode. Was bedeutet: Ich schreibe C-Code, welcher dann vom Compiler direkt in Maschinencode übersetzt wird, der direkt in der Cog läuft. Scheint ja nun doch nicht so zu sein, weshalb ich deinen Einwand zu den unterschiedlichen Geschwindigkeit der verschiedenen Modelle nicht wirklich verstehe - um nichts anderes ging es ja.

Mit einem gut optimierenden C-Compiler erreicht man sicher höhere Geschwindigkeiten als mit VMs.

Nur das die C-Compiler auf dem Prop halt alle VMs verwenden - ob nun LMM, XMM oder CMM.

[yeti]

Naja, ich bezog mich da mehr auf deine Aussage, dass PropGCC auch nativen Code für Cogs generieren kann. Unter nativem Code verstehe ich Maschinencode. Was bedeutet: Ich schreibe C-Code, welcher dann vom Compiler direkt in Maschinencode übersetzt wird, der direkt in der Cog läuft.

Genau das kann PropGCC.

Nur das die C-Compiler auf dem Prop halt alle VMs verwenden - ob nun LMM, XMM oder CMM.

NEIN!!!
Lies doch mal einer, was ich als Quellen angebe!

"COG" ist eines der Memory-Models, für die PropGCC Code generieren kann.

Memory Models

The Propeller port of GCC supports a number of memory models, or ways of storing the program in memory. Basically these models provide a trade off of speed for code space. By far the fastest model is the native “cog” model (-mcog) in which machine instructions are executed directly. However, in that model only the 2K of internal memory (actually slightly less) is available for code. In the other models (LMM, CMM, XMMC, and XMM) code is stored in RAM external to the cog and is loaded in by a small kernel. This makes more space available for the code (and, in the XMM case, the data) but at the cost of having kernel overhead on each instruction executed.

COG

As previously mentioned, in the COG memory model code is stored directly in the internal memory of the Propeller's cogs. This memory is 512 words, or 2048 bytes, long, but 16 words are reserved for hardware registers. The GNU C compiler reserves an additional 17 words for compiler registers. These registers, named r0-r14, lr, and sp, are used by the compiler for various purposes. r0-r7 are temporary registers within a function (not preserved across function calls). r8-r14 are working registers within a function and are preserved across function calls. lr is the “link register” which holds the return address for functions (except for functions declared with the “native” attribute, for which the return address is stored directly in the ret instruction). sp is the stack pointer.

Aufgrund von Hitzedemenz scheine ich aber wohl nicht in der Lage zu sein, dies zu erklären. Ich ziehe die Konsequenzen daraus und werde bis zum Eintreffen kühleren Wetters also zu diesem Thema schweigen.

[drohne235]

Ist ja cool, da kann man ja schön fein skalieren:

Viel Speicher/Langsam --> XMM - LMM - CMM - COG - ASM <-- Wenig Speicher/Sauschnell

NEIN!!!
Lies doch mal einer, was ich als Quellen angebe!

Nööö wozu denn, du hast das doch so schön rausgesucht...