Bauteiltöter hat geschrieben:Nein, der Compiler muss das "ret" stehen lassen, die Funktion könnte ja von einem anderen Modul aus aufgerufen werden. Er darf also aus der Funktion selber alles Rauswerfen weil es offensichtlich sinnlos ist, er darf die Funktion aber nicht komplett raus schmeißen. Das dürfte nur der Linker, der macht das aber nur mit aktiviertem LTO (link time optimization). Aktiviert wird das mit -flto, muss vermutlich compiler UND linker als Parameter mitgegeben werden. Ob da noch was zu beachten ist weiß ich jedoch nicht.
Ah, OK, das macht Sinn. Ich schätze, das -flto werde ich erstmal nicht benutzen, denn auf diese Weise sehe ich, wenn ich groben Unfug gemacht habe.
Bauteiltöter hat geschrieben:Ich habe den GCC 4.8.1, also etwas neuer als deiner.
Heh, hatte ich fast erwartet, Debian sta(b)le eben.
Bauteiltöter hat geschrieben:Optimierung war -O1, also optimize for speed, nicht for size. Könnte erklären warum er bei dir springt und es bei mir alles Inline erledigt hat.
Ja, das würde Sinn machen, so ein Sprung kostet ja "unnötig" Zeit. Da hab ich gleich
noch eine Frage: was machen dieses ominösen Sprünge, die überall auftauchen ("rcall .-3288 ; 0xfffff51e <__eeprom_end+0xff7ef51e>)? Panic Mode? Die Adresse 0xfffff51e taucht jedenfalls im Hexfile gar nicht auf, muß also irgendwas Festes sein.
Die sonstigen Optionen bin ich mal durchgegangen. Evtl. kommt durch "-ffunction-sections" und "-fdata-sections" zusätzlicher Overhead dazu, in der Manpage wird zumindest gewarnt:
avr-gcc manpage hat geschrieben:Only use these options when there are significant benefits from doing so. When you specify these options, the assembler and linker will create larger object and executable files and will also be slower. You will not be able to use "gprof" on all systems if you specify this option and you may have problems with debugging if you specify both this option and -g.
Bei -fpack-structs ist unklar, ob ich das nutzen kann, da ich (war aber nicht explizit Teil der Frage und auch im Prinzip irrelevant, fiel mir halt nur auf
) C und Assembler mische (ISR wie üblich in asm). Wird zwar im selben Schritt und mit ggfs. denselben Optionen ()außer -Mx assembliert, aber hmmja. Ansonsten macht das trotz der Warnung Sinn, die mickrigen 512 Bytes RAM möchte man ja ganz gern nicht mit Alignment verplempern.
-fshort-enums stört hingegen nicht, da der Assembler mit Enums eh nichts anfangen kann und ich sie deshalb nicht nutze, bzw. nur für C-Code nutzen würde.
Code: Alles auswählen
'-funsigned-char' '-funsigned-bitfields' '-D' 'DEBUG' '-O1' '-ffunction-sections' '-fdata-sections' '-fpack-struct' '-fshort-enums' '-g2' '-Wall' '-mmcu=atmega88' '-c' '-std=gnu99' '-v' '-MD' '-MP' '-MF' 'speedtest.d'
Bauteiltöter hat geschrieben:Irgendeinen vorteil der div()-Funktion muss es jedoch geben... <snip>
Auch gut zu sehen: -Os bringt hier einen erheblichen Geschwindigkeitsnachteil, das muss aber nicht immer so sein. Es gibt viele Situationen, wo -Os schneller und kleiner wird als -O1... -O3.
Komisch, ich sehe es auch so, daß da irgendein Vorteil liegen sollte... evtl. wollte irgendwer ja auch nur einen bequemeren Zugriff auf die Ergebnisse, aber... liegt vielleicht noch an den Optionen, auch, daß je nach Optimierungsstufe ggfs- was anderes rauskommt als erwartet.
Naja, ich danke Dir jedenfalls für Deine Einsichten und Tests!
Welchen Simulator benutzt Du eigentlich?