|
Anzeige
|
SRAM-Verbrauch für float division?
Gast
#898761
Hallo! Könnte mir bitte jemand den folgenden Effekt erklären? Sobald ich die Zeile
im Program habe, sind laut AVR Studio auf einmal ca. 250 Bytes im SRAM mehr belegt. Vermeide ich dabegen die float division mit
is der RAM Verbrauch wieder wie vorher. Gut, die zweitet Varinaten ist, sowieso besser, da ich damit auch Platz im flash spare. Aber warum verbraucht das dazu linken der float Funktionen Speicher im SRAM? Ich bin verwirrt... ;) Gruß Eiko
Gast
#898834
Weil "100" und "340" integers sind und "3.40" ein float ist. Somit ist "100"/"300" gar keine float sondern eine integer-division.
Gast
#898841
ja, dass is mir schon klar. Deshalb hab ich die Zeile ja auch geändert.
Die Frage war:
> Aber warum verbraucht das dazu linken der float Funktionen Speicher im
SRAM?
Gast
#898849
huch, 'Dieter' gehört zu nem anderen Forum. verdammte gespeicherte Formulareingaben. Die tauchen ständig in Feldern/Seiten auf, wo man sie gar nicht eingegeben hat ;)
Gast
#898860
Der Compiler wird 100/340 als Konstante setzen... Bei einer Integer-Division läuft das wohl auf eine Multiplikation mit 0 heraus :) Grüße Wäre noch interessant zu wissen, was in deiner Zuweisung vor dem '=' für ein Datentyp ist. Weist du das, was du geschickt mit '...' getarnt hast. Und was hat x für einen Datentyp? irgendwas = (float) * (int) ist nämlich eine Floatingpointoperation. (float) = irgendwas * (int) ebenso. Tim wrote: > Der Compiler wird 100/340 als Konstante setzen... > Bei einer Integer-Division läuft das wohl auf eine Multiplikation mit 0 > heraus :) Nein, wird er nicht, und läuft es nicht.
Gast
#899018
Welche Optimierung verwendest Du? Eventuell werden beim Linken irgendwelche Konstanten aus der float-lib abgespeichert. Eiko wrote: > Aber warum verbraucht das dazu linken der float Funktionen Speicher im > SRAM? Ich bin verwirrt... ;) Möglicherweise wird dabei die falsche Version einer Lib-Funktion reingezogen. Die generische GCC Version der Floating Point Funktionen benutzt eine 256 Byte Tabelle (=> __clz_tab oder so in der Art, zu finden im Map File). Nur sollte die nie zum Zuge kommen, weil eigentlich die Funktionen der avr-libc verwendet werden sollten. Das war insbesondere ein fatales Problem der WinAVR Version von Dezember 2007, wo die avr-libc nicht ganz zur Version des Compilers passte.
Gast
#899104
ja, das mit der Tabelle wird es sein. Findet sich auch im Map File wieder. Aber eigentlich dachte ich, ich hätte ne neuere Version. Muss ich morgen mal nach schauen. Und wann eine Division eine float und wann eine int Operation ist, war hier gar nicht das Thema ;) Antwort schreibenBitte melde dich an, um einen Beitrag zu schreiben. |
Anzeige
|
