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
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.
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 ;)
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.
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 ;)
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
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.
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.
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.
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
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:
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
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.
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.
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.
>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
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.
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.
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:
1
13:int8_tflagIR=1;
2
14:
3
15:intTestFunc(){
4
16:if(!flagIR){
5
07E808F4MOVFflagIR,F
6
07E91903BTFSCSTATUS,0x2
7
07EA0008RETURN
8
17:return;
9
18:}
10
19:flagIR++;
11
07EB3001MOVLW0x1
12
07EC00F0MOVWF__pcstackCOMMON
13
07ED0870MOVF__pcstackCOMMON,W
14
07EE07F4ADDWFflagIR,F
15
20:}
16
07EF0008RETURN
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
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.
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.
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...
... 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?
@ 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 ;-)
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
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.
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.
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.
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!
Thread beobachten
Seitenaufteilung abschalten