e-Fktn und ln für Atmel?

[uli (Gast)]

hallo, kann man eigentlich mit gcc auch exponential und ln Funktionen
realsieren? Ich habe gestern probiert in winarv eine Sinusfunktion zu
compilieren, hat aber nicht geklappt?

[Jörg W. (dl8dtl) (Moderator)]

> hallo, kann man eigentlich mit gcc auch exponential und ln
> Funktionen realsieren?

Wie wär's denn, einfach erstmal mit dem Lesen der Doku zu
beginnen?

[uli (Gast)]

ja, das habe ich schon gemacht, dann habe ich die beispiele genommen und
dort einfach einmal eine sinusberechnung gemacht, allerdings war dann in
der demo.ist Datei keine änderung gegenüber der alten zu sehen; es war
also kein zusätzlicher code generiert worden. habe ich etwas falsch
gemacht?

Die math.h habe ich natürlich eingebunden, und auch sonst waren keine
Fehlermeldungen zu sehen. Den Code selbst habe ich in eine while
schleife gelegt.

[Rolf Magnus (Gast)]

Machst du auch was mit dem Ergebnis? Sonst kann der Compiler auf die
Idee kommen, die Berechnung wegzuoptimieren.

[uli (Gast)]

ja ich multipliziere den wert mit einem intwert und speichere in in dem
intwert ab, und das in jeder schleife, oder soll ich ihn ausgeben ?

[Jörg W. (dl8dtl) (Moderator)]

Du musst irgendwas damit anstellen, das den Compiler dazu
veranlasst anzunehmen, dass der berechnete Wert auch benutzt
wird.

Eine Ausgabe ist natürlich die einfachste Form, er wird ja
wirklich benutzt.

Ein Abspeichern in einer globalen Variablen geht auch, wenn man in
jedem Durchlauf auch noch etwas tut, von dem der Compiler annehmen
muss, dass dieses Tun den berechnetn Wert benutzen könnte.  Ein Aufruf
einer Funktion wäre ein Beispiel, aber auch nur bedingt: für
Funktionen, die zur gleichen Zeit mit compiliert werden, kann der
Compiler u. U. feststellen, dass sie den Wert ja gar nicht benutzen
;-), und für Standardfunktionen der Bibliothek darf er (bei -fhosted,
das ist der default) implizit wissen, was sie tun (d.h. sie verwenden
den Wert natürlich auch nicht) (*).  Nicht-Standard-Funktionen der
Bibliothek müssten jedoch funktionieren.

Die Ergebnisvariable als `volatile' deklarieren, hilft natürlich auch
immer.

Die allerbeste Variante ist es aber, gar nicht erst auf die Idee zu
kommen, deine Tools wären zu blöd, ihre dokumentierte Funktionalität
auch wirklich implementiert zu haben.  Statt eines völlig sinnlosen,
übermäßig vereinfachten Tests, geh' also einfach mal davon aus, dass
die dokumentierten Funktionen auch wirklich funktionieren, und
schreibe lieber so viel von deinem gewünschten Algorithmus auf, dass
das Zeugs dann auch ernsthaft was tut.

(*) Das ist übrigens auch der Grund, warum er Aufrufe von sin() oder
log() wegoptimieren kann, wenn deren Ergebnis offensichtlich nicht
benutzt wird: er weiß, dass diese Funktionen sonst keinerlei
Seiteneffekte besitzen, d.h. keine globalen Variablen ändern etc. pp.
Auch hat es natürlich keinerlei Sinn, ein sin() von einem zur
Compilezeit konstanten Wert ,,berechnen'' zu wollen: der Compiler
darf
den Sinus des Wertes dann gleich selbst eintragen.

[uli (Gast)]

Meine Frage war ja auch wieviel code ein Atmel für eine Sinusberechnung,
eine exp-fktn oder eine ln - berechnung braucht. Da bringt es mir nichts
wenn ich da erst einmal gutgläubig seitenweiße sinnvollen code schreibe
und dann irgendwan feststelle das das ganze viel zu langsam ist.

[uli (Gast)]

Trotzdem danke für die Antwort

[Jörg W. (dl8dtl) (Moderator)]

> Meine Frage war ja auch wieviel code ein Atmel für eine
> Sinusberechnung, eine exp-fktn oder eine ln - berechnung braucht.

% avr-size exp.o sin.o log.o
   text    data     bss     dec     hex filename
    166       0       0     166      a6 exp.o
     38       0       0      38      26 sin.o
    132       0       0     132      84 log.o

(Hier für die avr4-Architektur, also ATmega8 etc.)

Vermutlich werden noch einzelne Teile der folgenden Objektmodule
ebenfalls benötigt:

% avr-size fp_*.o
   text    data     bss     dec     hex filename
     68       0       0      68      44 fp_cmp.o
     98       0       0      98      62 fp_cosinus.o
     10       0       0      10       a fp_flashconst.o
     58       0       0      58      3a fp_merge.o
      6       0       0       6       6 fp_nan.o
    152       0       0     152      98 fp_powerseries.o
     52       0       0      52      34 fp_split.o
     10       0       0      10       a fp_zero.o

[Rolf Magnus (Gast)]

Grad mal getestet:

#include <math.h>

int main()
{
    volatile double in = 1;
    volatile double out = sin(in);
}

avr-g++ -Os sin.c && avr-size
   text    data     bss     dec     hex filename
   1248       0       0    1248     4e0 a.out

Es wird aber nicht jede Funktion so viel brauchen. Wenn ich sin durch
log ersetzte, wird daraus:

  text    data     bss     dec     hex filename
   1086       0       0    1086     43e a.out

und mit beiden Aufrufen:

   text    data     bss     dec     hex filename
   1398       0       0    1398     576 a.out