SRAM-Verbrauch für float division?

[Eiko (Gast)]

Hallo!

Könnte mir bitte jemand den folgenden Effekt erklären?

Sobald ich die Zeile

... = x / 3.40;

 im Program habe, sind laut AVR Studio auf einmal ca. 250 Bytes im SRAM 
mehr belegt.

Vermeide ich dabegen die float division mit

... = x * 100 / 340;

 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

[Micha (Gast)]

Weil "100" und "340" integers sind und "3.40" ein float ist. Somit ist 
"100"/"300" gar keine float sondern eine integer-division.

[Dieter (Gast)]

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?

[Eiko (Gast)]

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 ;)

[Tim (Gast)]

Der Compiler wird 100/340 als Konstante setzen...
Bei einer Integer-Division läuft das wohl auf eine Multiplikation mit 0 
heraus :)

Grüße

[Ralf S. (spacedog)]

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.

[Stefan E. (sternst)]

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.

[Micha (Gast)]

Welche Optimierung verwendest Du? Eventuell werden beim Linken 
irgendwelche Konstanten aus der float-lib abgespeichert.

[Andreas K. (a-k)]

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.

[Eiko (Gast)]

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 ;)