gratis PIC compiler, der pipelining benutzt?

[A. S. (rava)]

hi,

ich programmiere gerade ein kleines hobbyprojekt mit einem 8bit PIC. 
Derzeit verwende ich den gratis-compiler von microchip (xc8 free). Wenn 
ich meinen Quelltext damit baue kommt irgendwann im Protokoll die 
Meldung

> Running this compiler in PRO mode, with Omniscient Code Generation enabled,
> often produces code which is 60% smaller and at least 400% faster than in
> Free mode. The MPLAB XC8 PRO compiler output for this code could be
> 6694 bytes smaller and run 4 times faster.

für mich klingen gerade die 400% Geschwindigkeitszuwachs, als würde das 
Ding kein pipelining unterstützen. Oder was meint ihr?


Ich erwarte keine allermodernsten state-of-the-art optimierungen, aber 
wenn der chip eine pipeline hat, dann würde ich die gerne auch verwenden 
können, ohne dem Hersteller >300 EUR für den Compiler zu zahlen, obwohl 
ich schon die MCUs an sich bezahle ;)
Bei der Konkurrenz klappt's ja auch!

Welche Alternative würde mich glücklich machen?
Da ich sicher noch einige Monate an dem Projekt sitzen werde, nützt mir 
eine Demo nicht wirklich.

ciao
rava

ps: PIC18F46K22

[Helmut S. (helmuts)]

Beim PIC18 gibt es nichts zum Pipelinen. Vielleicht benutzen die ja den 
31 Worte Hardware Stack etwas besser und müssen dadurch nicht den ganzen 
Stack in Software implementieren.
Nimm gleich PIC24 statt PIC18 wenn du auf mehr Rechenleistung aus bist. 
Der PIC24 hat eine um Welten bessere Prozessorarchitektur. Wenn es denn 
noch mehr werden soll nimm PIC32. Da du eh in C programmierst, musst du 
deren zugegebenermaßen komplexeren Assembler auch gar nicht lernen.

[A. S. (rava)]

hehe, danke aber die Hardware steht schon. Ist aber sicherlich ein guter 
Tip für's nächste Mal!
Ich komme aus Sicht der Rechenzeit einigermaßen hin, aber etwas Luft 
nach oben wäre natürlich luxuriös.


also keine pipeline.
diese garantierten >400% finde ich nur etwas happig.


ich bin ja bescheiden gebe mich auch mit 100% Geschwindigkeitszuwachs 
zufrieden, wenn's nichts kostet ;)

[Helmut S. (helmuts)]

Du kannst ja von Microchip die MPlab mit dem vollen Compiler als 
Testversion installieren und schauen ob das was bringt. Die Lizenz gilt 
dann zwar nur einige Wochen aber einenn Versuch wäre es ja wert.

[TTL (Gast)]

und garantiert wir da auch nichts !!  "often" "could"

[A. S. (rava)]

Helmut S. schrieb:
> Du kannst ja von Microchip die MPlab mit dem vollen Compiler als
> Testversion installieren und schauen ob das was bringt. Die Lizenz gilt
> dann zwar nur einige Wochen aber einenn Versuch wäre es ja wert.

darüber bin ich mir im Klaren, aber:

Szenario 1: Es bringt nichts
Dann hätte ich es mir auch sparen können.

Szenario 2: Code wird schneller
Ja super! Aber bis das Projekt abgeschlossen ist, brauche ich dann noch 
eine andere Lösung, denn die Trial-Zeit ist bis dahein durch.

Also suche ich lieber gleich eine für mich realistische Lösung, falls es 
die denn gibt.


Hat sich schonmal hier jemand durchprobiert?
PIC C-Compilervergleich

Falls die Liste vollständig ist: In Frage kommt neben dem XC8 wohl nur 
SDCC. Denn auf 1Byte-Datentypen kann ich irgendwie nicht verzichten ;)

[Frank K. (fchk)]

A. S. schrieb:

> Hat sich schonmal hier jemand durchprobiert?
> PIC C-Compilervergleich

HiTech wurde von Microchip gekauft. Der XC8 ist die Weiterentwicklung 
des HiTech-Compilers.

> Falls die Liste vollständig ist: In Frage kommt neben dem XC8 wohl nur
> SDCC. Denn auf 1Byte-Datentypen kann ich irgendwie nicht verzichten ;)

Ich würde einfach gar nichts machen und erst mal schauen, ob Du von der 
Rechenleistung hinkommst. Die höheren Optimierungsstufen sind eher für 
Firmen interessant, die damit ggf einen Baustein mit weniger Flash 
verwenden können, um Stückkosten zu sparen. Für Einzelstücke ist das 
aber irrelevant.

fchk

[Michael (Gast)]

Frank K. schrieb:
> Die höheren Optimierungsstufen sind eher für
> Firmen interessant, die damit ggf einen Baustein mit weniger Flash
> verwenden können, um Stückkosten zu sparen.

Bei einfachen Projekten mit Taster, LED, LC-Display usw. mag das 
stimmen.

Wenn man aber den Compiler zum "richtigen" Arbeiten braucht, sieht es 
schon ganz anders aus.

Sobald man mit Bussystemen arbeitet und mit Echtzeitanforderungen 
konfrontiert wird, ist es schon hilfreich, wenn man weiß, dass man sich 
auf sein Werkzeug verlassen kann.

Von wirklich timingkritischen Dingen wie Soft-UART usw. ganz zu 
schweigen.

Und bevor das Argument kommt, dass man dafür ja Assembler benutzen 
könne, frage ich, wieso braucht man dann überhaupt noch einen Compiler 
wenn man die komplexen Dinge sowieso selbst machen muss?

Einfachen Code kann ich auch sehr schnell in Assembler tippen...

Um zur Ausgangsfrage zurück zu kommen:

Die 8 Bit-PIC-Compiler in der kostenfreien Ausführung machen 
beispielsweise (absichtlich) Mist mit den "banksel"-Befehlen usw. So 
werden eigentlich überflüssige Anweisungen wiederholt, weil 
beispielsweise beide Speicherbereiche in derselben Bank liegen.

Oder aber die Reihenfolge wird nicht korrigiert.

Beispiel schlecht:

banksel Bank3
... Register A aus Bank3
banksel Bank4
... Register B aus Bank4
banksel Bank3
... Register C aus Bank3
Restlicher Code

Beispiel gut:

banksel Bank3
... Register A aus Bank3
... Register C aus Bank3
banksel Bank4
... Register B aus Bank4
Restlicher Code

Schon hat man ein oder zwei Befehle gespart (je nach PIC).

In der kostenpflichtigen Variante hingegen wird dies bei der Optimierung 
abgefangen.

[Kindergärtner (Gast)]

PROTIP: 3€ mehr für den Mikrocontroller ausgeben, 300€ für den Compiler 
sparen - indem man eine Architektur nimmt, für die es sehr gut 
optimierende freie Compiler gibt, wie z.B. Cortex-M und damit den GCC.

[./. (Gast)]

int i;
float x,y;
float sin(float);

main()
{
  for(i=0;i<=360;i++)
  {
    x = i * 1.0;
    y=sin(x);
  }
}

Executing: "xc8.exe" --pass1 WRK.C -q --chip=18F46K22 -P --runtime=default,+clear,+init,-keep,+osccal,-download,-resetbits,-stackcall,-config,+clib,+plib --opt=default,+asm,-debug,-speed,+space,9 --warn=0 -N255 -D__DEBUG=1 -Bsmall --double=32 --float=32 --addrqual=ignore -g --asmlist "--errformat=Error   [%n] %f; %l.%c %s" "--msgformat=Advisory[%n] %s" "--warnformat=Warning [%n] %f; %l.%c %s" 
Executing: "xc8.exe" -oWRK.cof -mWRK.map --summary=default,-psect,-class,+mem,-hex --output=default,-inhx032 WRK.p1 --chip=18F46K22 -P --runtime=default,+clear,+init,-keep,+osccal,-download,-resetbits,-stackcall,-config,+clib,+plib --opt=default,+asm,-debug,-speed,+space,9 --warn=0 -N255 -D__DEBUG=1 -Bsmall --double=32 --float=32 --addrqual=ignore -g --asmlist "--errformat=Error   [%n] %f; %l.%c %s" "--msgformat=Advisory[%n] %s" "--warnformat=Warning [%n] %f; %l.%c %s" 
Microchip MPLAB XC8 C Compiler (PRO Mode) V1.31
Copyright (C) 2014 Microchip Technology Inc.
License type: Node Configuration

Warning [1090] WRK.C; 2. variable "_y" is not used

Memory Summary:
    Program space        used   BD4h (  3028) of 10000h bytes   (  4.6%)
    Data space           used    6Bh (   107) of   F38h bytes   (  2.7%)
    Configuration bits   used     0h (     0) of     7h words   (  0.0%)
    EEPROM space         used     0h (     0) of   400h bytes   (  0.0%)
    ID Location space    used     0h (     0) of     8h bytes   (  0.0%)
    Data stack space     used     0h (     0) of   993h bytes   (  0.0%)

Loaded WRK.cof.

********** Build successful! **********

Executing: "xc8.exe" --pass1 WRK.C -q --chip=18F46K22 -P --runtime=default,+clear,+init,-keep,+osccal,-download,-resetbits,-stackcall,-config,+clib,+plib --opt=default,+asm,-debug,-speed,+space,9 --warn=0 -N255 -D__DEBUG=1 -Bsmall --double=32 --float=32 --addrqual=ignore -g --asmlist "--errformat=Error   [%n] %f; %l.%c %s" "--msgformat=Advisory[%n] %s" "--warnformat=Warning [%n] %f; %l.%c %s" 
Executing: "xc8.exe" -oWRK.cof -mWRK.map --summary=default,-psect,-class,+mem,-hex --output=default,-inhx032 WRK.p1 --chip=18F46K22 -P --runtime=default,+clear,+init,-keep,+osccal,-download,-resetbits,-stackcall,-config,+clib,+plib --opt=default,+asm,-debug,-speed,+space,9 --warn=0 -N255 -D__DEBUG=1 -Bsmall --double=32 --float=32 --addrqual=ignore -g --asmlist "--errformat=Error   [%n] %f; %l.%c %s" "--msgformat=Advisory[%n] %s" "--warnformat=Warning [%n] %f; %l.%c %s" 
Microchip MPLAB XC8 C Compiler (Free Mode) V1.31
Copyright (C) 2014 Microchip Technology Inc.
License type: Node Configuration

Warning [1273] ; . Omniscient Code Generation not available in Free mode

Memory Summary:
    Program space        used   F28h (  3880) of 10000h bytes   (  5.9%)
    Data space           used    79h (   121) of   F38h bytes   (  3.1%)
    Configuration bits   used     0h (     0) of     7h words   (  0.0%)
    EEPROM space         used     0h (     0) of   400h bytes   (  0.0%)
    ID Location space    used     0h (     0) of     8h bytes   (  0.0%)
    Data stack space     used     0h (     0) of   986h bytes   (  0.0%)

Running this compiler in PRO mode, with Omniscient Code Generation enabled,
often produces code which is 60% smaller and at least 400% faster than in
Free mode. The MPLAB XC8 PRO compiler output for this code could be
2320 bytes smaller and run 4 times faster.
See http://www.microchip.com for more information.

Loaded WRK.cof.

********** Build successful! **********

[Andreas S. (andreas) (Admin)]

90% des Programmcodes dürften in diesem Fall die float-Bibliothek und 
die sin-Funktion verschlingen, welche vermutlich in beiden 
Compilerversionen identisch sind. Insofern ist das Ergebnis nicht sehr 
aussagekräftig.

[Frank K. (fchk)]

Michael schrieb:

> Wenn man aber den Compiler zum "richtigen" Arbeiten braucht, sieht es
> schon ganz anders aus.

Dann kauft Du auch die Lizenz.

> Oder aber die Reihenfolge wird nicht korrigiert.
>
> Beispiel schlecht:
>
> banksel Bank3
> ... Register A aus Bank3
> banksel Bank4
> ... Register B aus Bank4
> banksel Bank3
> ... Register C aus Bank3
> Restlicher Code
>
> Beispiel gut:
>
> banksel Bank3
> ... Register A aus Bank3
> ... Register C aus Bank3
> banksel Bank4
> ... Register B aus Bank4
> Restlicher Code

Oh, DAS kann aber auch nach hinten losgehen. Im C-Standard steht ganz 
klar drin, dass der Compiler niemals die Reihenfolge von Anweisungen 
ändern darf. Es könnten ja SFRs sein, bei denen das gerade nicht egal 
ist.

Siehe Abschnitt 5.1.2.3 "Program execution", Absatz 2:
"Accessing a volatile object, modifying an object, modifying a file, or 
calling a function that does any of those operations are all side 
effects, which are changes in the state of the execution environment. 
Evaluation of an expression may produce side effects. At certain 
specified points in the execution sequence called sequence points, all 
side effects of previous evaluations shall be complete and no side 
effects of subsequent evaluations shall have taken place. (A summary of 
the sequence points is given in annex C.)"

fchk

[schrieb schrieb schrieb (Gast)]

Frank K. schrieb:
> Oh, DAS kann aber auch nach hinten losgehen. Im C-Standard steht ganz
> klar drin, dass der Compiler niemals die Reihenfolge von Anweisungen
> ändern darf. Es könnten ja SFRs sein, bei denen das gerade nicht egal
> ist.

Diese Register müssen volatile deklariert sein. Falls nicht hat der 
Programmierer einen Fehler gemacht. Bei allen anderen Registern / 
Variablen ist die Reihenfolge egal.

Zum Beispiel darf der Compiler hier die Reihenfolge der Zuweisung 
vertauschen:

int a;
int b;
a = 5;
b = 3;

Hier darf er das nicht:

volatile int a;
volatile int b;
a = 5;
b = 3;

[Axel S. (a-za-z0-9)]

A. S. schrieb:
> Welche Alternative würde mich glücklich machen?

Daumen mal Fensterkreuz: Alles was kein 8-Bit PIC ist. Es ist kein 
zufall, daß es für diese verkorkste Architektur keinen freien C-Compiler 
gibt. Und in Assembler will mit die Teile schon gar nicht programmieren.


XL

[... (Gast)]

http://www.t4f.org/articles/optimization-of-microchip-pic-xc8-compiler-in-free-and-pro-mode/

[Helmut S. (helmuts)]

... schrieb:
> 
http://www.t4f.org/articles/optimization-of-microchip-pic-xc8-compiler-in-free-and-pro-mode/

Da bin ich jetzt aber enttäuscht von Microchip, dass die in der 
kostenlosen Version zusätzlich "Bremsen" einbauen.

[TU Student 1. (student0)]

Nimm eventuell einen älteren HI-Tech C Compiler, bevor die 
"Desoptimierung" gemacht wurde.   Ansonsten gab es auch den Microchip 
C18 Compiler, da war die Abschaltung der Optimierung nach 30 Tagen nicht 
so tragisch.

Was ich an HI-Tech C mochte, war, dass tatsächlich auch "anständiger" 
ANSI Standard C-Code effizient und bug-frei kompiliert wurde und dass 
man auch sprintf() problemlos  auch auf einem PIC16F887 nutzen konnte 
(ja, soll man nicht tun,  aber wenn der PIC sowieso sonst zu 5% 
ausgelastet wäre, macht es nichts)

Axel Schwenke schrieb:
> A. S. schrieb:
>> Welche Alternative würde mich glücklich machen?
>
> Daumen mal Fensterkreuz: Alles was kein 8-Bit PIC ist. Es ist kein
> zufall, daß es für diese verkorkste Architektur keinen freien C-Compiler
> gibt. Und in Assembler will mit die Teile schon gar nicht programmieren.
>
> XL

Bis zu einer Codegrösse von 2K tut Assembler wirklich nicht weh - 
darüber sollte man wohl heutzutage gleich an C und 16/32-Bit denken.

Aber ein kleines Programm vom Typ "Pin-high-dann-LED-an" ohne viel 
Mathematik oder String-Verarbeitung ist in ASM schneller geschrieben als 
in C.  Und der PIC-Assembler ist einer der einfachsten, die es gibt.

[Ralph (Gast)]

Helmut S. schrieb:
> Da bin ich jetzt aber enttäuscht von Microchip, dass die in der
> kostenlosen Version zusätzlich "Bremsen" einbauen.

Microchip hat da keine Bremsen eingebaut.
Die haben nur den Optimizer nicht freigeschaltet.

Den gibt es halt nur in der Lizenzversion.

[... (Gast)]

> Microchip hat da keine Bremsen eingebaut.
> Die haben nur den Optimizer nicht freigeschaltet.

Du hast

http://www.t4f.org/articles/optimization-of-microchip-pic-xc8-compiler-in-free-and-pro-mode/

gelesen. [ ]

[Peter D. (peda)]

Helmut S. schrieb:
> Da bin ich jetzt aber enttäuscht von Microchip, dass die in der
> kostenlosen Version zusätzlich "Bremsen" einbauen.

Nö.
Zuerst übersetzt der Compiler formal jeden Ausdruck in Assembler.
Und dann erst kommt der Optimizer ran.
Und da Du den Optimizer nicht bezahlt hast, ist er in der freien Version 
auch nicht dabei.

Es wurde also nichts zusätzlich eingebaut, sondern ein Schritt 
weggelassen.

[hauspapa (Gast)]

>ohne dem Hersteller >300 EUR für den Compiler zu zahlen, obwohl
>ich schon die MCUs an sich bezahle ;)

>Da ich sicher noch einige Monate an dem Projekt sitzen werde...

Hast Du Zeit dich mit unnötigen Problemen herumzuärgern? Lohnt es sich 
bei Euch auf Herstellersupport zu verzichten?
Mein Vorgesetzter würde bei der Konstellation nicht lange fackeln.
Mal abgesehen davon, das es meist nicht sinnvoll ist, sich für nur ein 
Projekt in eine neue Software einzuarbeiten. Das kommt schlicht zu 
teuer.

viel Erfolg
Hauspapa

[Helmut S. (helmuts)]

Peter Dannegger schrieb:
> Helmut S. schrieb:
>> Da bin ich jetzt aber enttäuscht von Microchip, dass die in der
>> kostenlosen Version zusätzlich "Bremsen" einbauen.
>
> Nö.
> Zuerst übersetzt der Compiler formal jeden Ausdruck in Assembler.
> Und dann erst kommt der Optimizer ran.
> Und da Du den Optimizer nicht bezahlt hast, ist er in der freien Version
> auch nicht dabei.
>
> Es wurde also nichts zusätzlich eingebaut, sondern ein Schritt
> weggelassen.

Lies bitte hier.
http://www.t4f.org/articles/optimization-of-microchip-pic-xc8-compiler-in-free-and-pro-mode/
Da wird gezeigt, dass hier absichtlich unnützer Code hineincompiliert 
wird um die PRO-Version besser aussehen zu lassen.

[(prx) A. K. (prx)]

Peter Dannegger schrieb:
> Zuerst übersetzt der Compiler formal jeden Ausdruck in Assembler.
> Und dann erst kommt der Optimizer ran.

Diese Vorgehensweise ist unüblich. Normalerweise erzeugt ein nicht 
trivialer Compiler aus dem Quellcode strukturell einfachen Zwischencode 
(kann auch ein Baum sein) und führt darin wesentliche 
Optimierungsschritte durch, lange bevor es zur eigentlichen 
Codegenerierung kommt. Allenfalls ein paar abschliessende Optimierungen 
finden im Nachhinein statt (peephole optimization).

> Und da Du den Optimizer nicht bezahlt hast, ist er in der freien Version
> auch nicht dabei.

Oder er ist drin, wird aber nicht genutzt. Ich hatte mir aufgrund dieser 
Frage mal einen Microchip-Compiler angesehen, der auf GCC basierte. Der 
einzige Unterschied zwischen Bezahlversion und freier Version war das 
Resultat der Lizenzabfrage. Davon abhängig reichte das Steuerprogramm 
des Compilers die entsprechenden Optionen an den eigentlichen Compiler 
durch - oder eben nicht.

[Nobby Nic (Gast)]

In den neueren Versionen des XC8 werden zumindest im Free Mode keine 
unnötigen GOTOs eingebaut um den Code zu strecken.

[Klaus (Gast)]

Helmut S. schrieb:
> Lies bitte hier.
> 
http://www.t4f.org/articles/optimization-of-microchip-pic-xc8-compiler-in-free-and-pro-mode/
> Da wird gezeigt, dass hier absichtlich unnützer Code hineincompiliert
> wird um die PRO-Version besser aussehen zu lassen.

Das "absichtlich" möchte ich stark in Zweifel ziehen. Ich hab mal 
versucht, einige der Beispiele nachzuvollziehen, es ist mir nicht 
gelungen. Das mag daran liegen, daß aus dem C-code wenig zu entnehmen 
ist, weder ob die Variablen int8, uint8 oder int sind, noch ob sie 
lokal, global oder volatile sind. Hier mal ein Fall nach dem Artikel:

13:            int8_t flagIR = 1;
14:            
15:            int TestFunc() {
16:                if (!flagIR) {
07E8  08F4     MOVF flagIR, F
07E9  1903     BTFSC STATUS, 0x2
07EA  0008     RETURN
17:                    return;
18:                }
19:                flagIR++;
07EB  3001     MOVLW 0x1
07EC  00F0     MOVWF __pcstackCOMMON
07ED  0870     MOVF __pcstackCOMMON, W
07EE  07F4     ADDWF flagIR, F
20:            }
07EF  0008     RETURN

Nichts von mehreren Gotos. Das "flagIR++" mußte ich noch einfügen, weil 
der Compiler aus der Funktion nur ein RETURN gemacht hat, da die Abfrage 
ja sinnlos ist (auch ohne optimization).
Selbstverständlich gabs auch die Erinnerung an die Pro-Version. (XC8 V 
1.31)
Ich hab noch ein weiteres Beispiel probiert, da der Assemblercode so 
anders war als in dem Artikel, hab ich aufgegeben.

MfG Klaus

[Peter D. (peda)]

Wenn ich das mal mit dem AVR-GCC vergleiche, mit -O0 wird der Code zwar 
aufgebläht, aber mit System.
Es wird alles auf 16Bit erweitert, es wird jeder Ausdruck ausgeführt, 
egal, ob das Ergebnis gebraucht wird oder nicht und es wird auch nichts 
umsortiert.

Ich denke schon, daß die Compiler in mehreren Durchgängen arbeiten und 
zuerst einfach nur den Code formal richtig übersetzen. Dann mag es schon 
scheinen, daß unnützer Code erzeugt wird.

Und erst in weiteren Durchläufen wird nach und nach optimiert.
Es wird z.B. nach Codemustern gesucht, die er dann durch (hoffentlich) 
effektivere ersetzt.
Es ist z.B. egal, ob man eine Schleife mit for, while, do-while oder 
if-goto bastelt, der Assembler sieht fast immer gleich aus.

[(prx) A. K. (prx)]

Peter Dannegger schrieb:
> Ich denke schon, daß die Compiler in mehreren Durchgängen arbeiten und
> zuerst einfach nur den Code formal richtig übersetzen.

Mehrere Durchgänge in engeren Sinn gab es bei Compilern, die anders 
nicht in den Speicher passten. Es gibt allerdings etliche Module, die 
optional die internen Zwischencodes optimieren, und die werden je nach 
Schalter ausgelassen.

Bei Microchip kommt allerdings hinzu, dass die eine zusätzliche 
Optimierung einbauten, die kleine identische Codestückchen zusammenlegt, 
um Platz zu sparen. Da sie das nicht im GPL-Code machen konnten, ohne 
den eigenen Code offenlegen zu müssen, blieb ihnen nichts anderes übrig, 
als diese Optimierung in ein separates Programm auszulagern.

> Dann mag es schon scheinen, daß unnützer Code erzeugt wird.

Unnützer Code ist ohne Optimierung nicht weiter ungewöhnlich. Dafür 
typisch sind redundante Transportbefehle. Beispielsweise wenn die erste 
Codesequenz mit MOV r1,r2 aufhört und die nächste unabhängig davon 
generierte Codesequenz mit MOV r2,r1 angfängt.

> Es wird z.B. nach Codemustern gesucht, die er dann durch (hoffentlich)
> effektivere ersetzt.

Das ist der letzte Schritt, um verbliebenen Unfug zu reparieren. Die 
weitaus meisten Optimierungsschritte erfolgen vorher, in den 
Zwischencodephasen. Registeroptimierungen, Änderung der Reihenfolge, 
Ersatz teurer durch billigere Operationen (z.B. Mult/Div durch Shift) 
etc. erfolgen lange vor der Codegenerierung.

Später bei der Codegenerierung werden Muster im Zwischencode 
identifiziert, aus denen dann gleich der bessere Code erzeugt wird (z.B. 
generische Addition vs. Addition einer Konstanten). Grenzen findet das 
dort, wo der Autor keine Lust hatte, noch den exotischsten Fall einzeln 
abzuhandeln und dann eine generische Sequenz greift.

> Es ist z.B. egal, ob man eine Schleife mit for, while, do-while oder
> if-goto bastelt, der Assembler sieht fast immer gleich aus.

Weil die entsprechenden Schemata bereits in den Zwischencodeschritten 
erkannt und angeglichen werden.

[Johann L. (gjlayde)]

Klaus schrieb:
> Helmut S. schrieb:
>> Lies bitte hier.
>>
> 
http://www.t4f.org/articles/optimization-of-microchip-pic-xc8-compiler-in-free-and-pro-mode/
>> Da wird gezeigt, dass hier absichtlich unnützer Code hineincompiliert
>> wird um die PRO-Version besser aussehen zu lassen.
>
> Das "absichtlich" möchte ich stark in Zweifel ziehen.

Sehe ich genauso.

Der erzeugte Code sieht für einen nicht-optimierenden Compiler durchaus 
plausibel aus und weist viele Analogien mit Code auf, den etwa GCC ohne 
Optimierung erzeugt — selbst wenn sich Zielarchitektur und 
Compilerarchitektur deutlich unterscheiden:

  > "XC8 insert two useless instructions that moves the assigned value
  >  to a temporally variable and then it read it."

Dennoch ist die Arbeitsweise unterschiedlicher Compiler weitaus 
ähnlicher als die Arbeitsweise von Compiler und Hirn, was dann zu 
Aussagen führt wie

  > "The logic says that the assembled code should be exactly the
  >  same! [...] XC8 doesn't respond to logic or reason"

und:

 > "Where this 40% of improvement comes? From real optimizations
 > or from removing those useless artifacts that seems to be
 > inserted on purpose?"

Das zeigt lediglich, daß der Autor nicht versteht, wie Compiler intern 
arbeiten...

[Markus G. (markus_ac)]

... schrieb:
> 
http://www.t4f.org/articles/optimization-of-microchip-pic-xc8-compiler-in-free-and-pro-mode/

Sehr interessanter Artikel. Wobei man bei dem Autor ja auch eine 
grundlegende Abneigung gegen Microchip erkennen kann - wie schlecht doch 
die Controller damals waren usw - und sich deshalb fragen sollte, ob das 
wirklich so extrem wie dargestellt ist, oder er "zufällig" solche 
Code-Schipsel ausgewählt hat, die den Code so stark aufblähen.

Wie auch immer. Das ist über den XC8.

Ich habe Ähnliches mal mit dem XC32 getestet (mit der Free und der 
60-tage PRO Trial Lizenz), ohne das im Detail zu dokumentieren.
Hierbei waren die Ergebnisse so, dass sich die Anschaffung des PRO 
Compilers nicht lohnte.
Ich weiß es nicht mehr 100%ig; aber bei etwa 25k Code Größe waren es 
weniger als 50 Byte Unterschied zwischen PRO und FREE Version.

Hat sonst noch jemand mit dem XC32 Compiler solche Test gemacht und kann 
seine Erfahrungen hier auch mal kundtun?

[Falk B. (falk)]

@ Johann L. (gjlayde) Benutzerseite

>Der erzeugte Code sieht für einen nicht-optimierenden Compiler durchaus
>plausibel aus und weist viele Analogien mit Code auf, den etwa GCC ohne
>Optimierung erzeugt — selbst wenn sich Zielarchitektur und
>Compilerarchitektur deutlich unterscheiden:

Kann schon sein.

>Das zeigt lediglich, daß der Autor nicht versteht, wie Compiler intern
>arbeiten...

Naja, muss er auch nicht, für Otto-Normalprogrammierer zählt das 
Ergebnis. Compiler-Versteher kommt gleich nach Frauenversteher ;-)

[Carsten S. (dg3ycs)]

Hi,

Markus Göbbels schrieb:
> Hat sonst noch jemand mit dem XC32 Compiler solche Test gemacht und kann
> seine Erfahrungen hier auch mal kundtun?

Also richtig systematisch habe ich solche Test nicht gemacht, wohl aber 
zumindest mal kleine Versuche...
Und da waren sowohl beim XC32 wie auch beim C18 die Unterschiede 
zwischen den Free und Pro Versionen nicht wirklich gravierend.

Üblicherweise eher so im Bereich 10% und kleiner! Bei C18 & Ram 
Verbrauch -die in einigen meiner Anwendungen kritischere Variable- war 
faktisch gar kein Unterschied.

Wobei ich auch das Vorurteil des "Schreibers" das der C18 unbenutzbar 
ist/war überhaupt nicht teilen kann. Ja, die eine oder andere Macke 
zeigte sich mal, aber gemeine Fallen oder ernsthafte Probleme habe ich 
nie entdeckt.

Beim XC8 und diesen "gewaltigen Versprechen für mehr Leistung" denke ich 
muss man einfach sehen das -wie vom Autor des Textes richtig erkannt- 
der XC 8 nur die Fortführung des HiTech Compilers ist, ein Produkt einer 
Firma die ihr Geld mit dem Compilerverkauf verdient hat und alleine vom 
zahlreichen Verkauf der Lizenzen leben musste. Da gehört Trommeln nun 
einmal zum Handwerk!
Und microchip ist ein Hardwarehersteller ohne eine wirklich große 
Softwareabteilung. Und da dort derzeit einige Umbrüche im Bereich Tools, 
Framework & Architektur laufen sind haben die paar Softwerker gerade 
massiv an jeder Ecke Baustellen. Es sit daher anzunehmen das aber mit 
jeder kommenden Version sich die free & pro Version weiter annähern und 
auch diese "Werbewarnungen" realistischer werden bis ein ähnliches 
Verhältniss wie bei den alten C Compilern (c18, C32 usw) erreicht ist.

BTW: Was mir an dem Artikel besonders aufstösst ist das der Schreiber 
teilweise einige fakten wirklich sehr undifferenziert bis falsch 
wiedergibt. So wirft er (durch die Blume) Microchip vor die Kunden zum 
Kauf der Lizenzen nötigen zu wollen - wo doch ANDERE HERSTELLER solche 
Compiler einfach Kostenlos dazugeben.

Dabei ist es doch gerade bei den von ihm aufgezählten gcc basierneden 
Compilern so das ursprünglich gar nicht von den Herstellern selbst 
gekommen sind, oder?

Und das er eine Codegrößenbeschränkte Version eines Compilers einer 
nicht größenbeschränkten Version mit geringerer Optimierung vorzieht ist 
auch extremst fragwürdig und erzeugt bei mir den Eindruck das es nur ein 
weiteres Alibiargument ist um etwas zu kritisieren.
Bei Microchip habe ich bisher noch jedes Projekt realisiert bekommen, 
wobei die Projekte im 8Bit Bereich in den letzten JAhren eher in 
Richtung 5-7kWord Programmgröße statt im Bereich 1-2kWord Programmgröße 
gelegen haben. Im 32Bit Bereich war fast nichts unterhalb 32kWord, aber 
vieles über 64kWord. Teilweise DEUTLICH!
Bei den "meisten" Codegrößenbeschränkten Compilern wäre es also 
Kaufversion überhaupt nicht gegangen. Und das soll besser sein?
Mal ganz davon abgesehen das auch nur ein Teil der 
Codegrößenbeschränkten Gratiscompiler überhaupt kommerziell eingesetzt 
werden darf. Die freien Microchip Compiler aber im vollen Umfang!

Davon abgesehen: Natürlich wäre es mir selbst am auch am liebsten völlig 
unbeschränkte, maximal optimierende, Tools kostenlos für die 
kommerzielle und private Verwendung zu haben.
Und ja so etwas gibt es für einige Architekturen.

Allerdings zählt für mich nur was am Ende unterm Strich herauskommt.
Wenn ich mit einem schlecht Optimierenden Compiler auf einem günstigen 
und gut verfügbaren µC mein Projekt zuverlässig realisiert bekomme 
interessiert es mich am ende nicht mehr ob nun 10 oder 40% vom Speicher 
leer bleiben. Und es ist mir allemal lieber als mit einer Architektur zu 
Arbeiten wo ich zwar tolle Compiler habe, dafür aber 
Verfügbarkeitsprobleme (mit langen Wartezeiten) bei den µC und/oder 
deutlich länger bis zur Fertigstellung des Projektes brauche da die 
kommerziell verwendbaren Beispielcodes oder gar die Peripherievielfalt 
nicht mal annähernd so Umfangreich sind.
Da wird die Frage nach der technischen Güte des Compilers schnell rein 
Akademisch. Denn Cheffe will immer nur wissen ob es funktionieren wird 
und wie lange wir brauchen werden!

Gruß
Carsten

[A. S. (rava)]

hi leute,

danke nochmal für die Diskussion. Echt spannend, was da alles gekommen 
ist!


Bei mir handelt es sich um ein Hobbyprojekt. Mein Chef ist mein Konto ;)
Ich gebe euch deswegen in der pragmatischen Sichtweise weitestgehend 
recht: Wenn's läuft, dann reicht's dass es läuft.

Was ich hier habe ist ein KommunikationsSlave, der alle Nase lang 
externe Interrupts bekommt und mit jedem dieser Interrupts eines der 
zuletzt empfangenen SPI-Bytes in einen größeren Buffer ablegt.
Bevor ich Zeitmessungen machen wollte, um herauszufinden, wie schnell 
diese INT0-Flanken kommen dürfen, wollte ich eben fragen, ob der Code 
noch eine Ecke schneller geht, sonst mache ich die Messungen zweimal.

Ich habe zwar kaum Ahnung vom Compilerbau, aber so wie sich das bisher 
liest, wird in einem so kurzen Programmschnipsel kaum die Möglichkeit 
bestehen, groß etwas herauszuholen. Aber wie gesagt: mein Gesamtprogramm 
hat auch etwa 10kB.

void interrupt high_priority ISR_highPriority()
{
    // external interrupt INT0 (i.e. Latch Clock)
    if(INTCONbits.INT0F == 1)
    {
        INTCONbits.INT0F = 0;

        switch(currentPhase)
        {
            case (...):
                ...
                break;
            case RUNNING:
                // copy SPI byte into large buffer
                quadBuffer[quadBufferWriteIndex].data[quadBufferWriteDataIndex] = SSP1BUF;
                // send output byte
                SSP1BUF = outputByte;
                // go to next slot in input buffer
                quadBufferWriteDataIndex++;
                // if write cycle has completed find new unused buffer slot to write to
                if(quadBufferWriteDataIndex >= quadBufferWriteDataMaxIndex)
                {
                    // finalize current buffer write action
                    quadBufferWriteIndexLast = quadBufferWriteIndex;
                    // flip quad buffer, i.e. find free slot for next buffer
                    do
                    {
                        quadBufferWriteIndex++;
                        if(quadBufferWriteIndex >= 4)
                            quadBufferWriteIndex = 0;
                    }
                    // do not accept a slot that is currently being read from
                    while(quadBufferWriteIndex == quadBufferReadIndex);
                    // reset this new buffer
                    quadBufferWriteDataIndex = 0;
                }
                break;
        }
    }
    (...)
}

Da also der ganze Zauber der Alternativcompiler von euch jetzt 
kaputtgemacht wurde, fange ich demnächst mit den Messungen an.

danke :)

[./. (Gast)]

So einen kleinen Fitzel kann man ja noch in Assembler schreiben.

[A. S. (rava)]

logo, aber die Frage war bewusst allgemein gehalten ;)
so habe ich mehr gelernt; schätze, ich war nicht der Einzige

[Johann L. (gjlayde)]

A. S. schrieb:
> quadBufferWriteIndex

Ist das etwa volatile?  Falls ja, hast du in der ISR mehr 
Speicherzugriffe als es eigentlich braucht --> lokale Kopie der Variable 
machen und am Ende zurückschreiben.  Bedingung ist, daß die IST atomar 
läuft, d.h. nicht von einer anderen ISR die in den gleichen Daten 
rumfummelt, unterbrochen werden kann.

[Takao K. (takao_k)]

Der serielle port wird durch besseren Compiler nicht schneller.

Ist ja auch eine tolle Mentalitaet alles soll gratis sein.

Microchip ist hier grosszuegig, alles frei verwendbar.

Ist nicht 4x langsamer das stimmt so garnicht.

[Markus G. (markus_ac)]

Carsten Sch. schrieb:
> Also richtig systematisch habe ich solche Test nicht gemacht, wohl aber
> zumindest mal kleine Versuche...
> Und da waren sowohl beim XC32 wie auch beim C18 die Unterschiede
> zwischen den Free und Pro Versionen nicht wirklich gravierend.
>
> Üblicherweise eher so im Bereich 10% und kleiner! Bei C18 & Ram
> Verbrauch -die in einigen meiner Anwendungen kritischere Variable- war
> faktisch gar kein Unterschied.

Ok, dann sind meine Tests ja garnicht so abwegig.
Danke für die Info!