www.mikrocontroller.net

Forum: Compiler & IDEs arm-elf-gcc float = double?


Autor: Karl Zeilhofer (griffin27)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich verwende den arm-elf-gcc mit WinARM.

Ich verwende den AT91SAM7A3, ein ARM7 ohne Floating-Point Unit. D.h. 
gleitkommaberechnungen müssen sowieso emuliert werden.

Im  Tutorial hier:
http://www.mikrocontroller.net/articles/ARM-elf-GCC-Tutorial
wird behauptet, doubles werden mit 64 bit gespeichert, so wie es auch 
IEEE-754 (http://de.wikipedia.org/wiki/IEEE_754) vorsieht.

Leider musste ich nun feststellen, dass double-variablen nur einem float 
entsprechen. Das ist für mich ein großes Problem, weil die Berechnungen 
mit float durch Rundungsfehler unbrauchbar werden.

Hat jemand schon diese Erfahrungen gemacht?
Kann man dem Compiler irgendwie mitteilen, dass er doubles richtig 
umsetzen soll?

lg, Karl

: Verschoben durch Moderator
Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Karl Zeilhofer schrieb:
> Leider musste ich nun feststellen, dass double-variablen nur einem float
> entsprechen.

Wie hast du das denn festgestellt?
$ cat foo.c
double pi = 3.1415926;
float pi_4 = 0.785;
$ arm-elf-gcc -c foo.c
$ arm-elf-nm --print-size foo.o
00000000 00000008 D pi
00000008 00000004 D pi_4
$

Autor: Martin Thomas (mthomas) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>...
>Hat jemand schon diese Erfahrungen gemacht?
>...
Nein.

Randnotiz: mein WinARM-Projekt liegt auf Eis und das so lange, wie 
Codesourcery in CS G++ lite das "fertig vorgekaut" bereitstellt, was ich 
in meinen Entwicklungen benötige. Ehedem war die Toolchain in WinARM 
etwas besonderes (v.a. keine Cygwin-Abhängigkeiten, syscalls nicht fest 
"verdrahtet"). Das findet man inzwischen aber auch woanders. Falls 
möglich also auf Codesourcery CS G++ lite oder alternativ Yagarto oder 
DevkitARM umsteigen. Die sind moderner und werden besser gepflegt.

Autor: Karl Zeilhofer (griffin27)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Danke Jörg für deine rasche Antwort.
So wie du es getestet hast, komme ich genau auch auf deinen Output.
Ich kenn das nm-tool aber nicht...

Nun, ich habe einen Digitalen Filter implementiert. Der ist mit double 
stabil, und mit float instabil.
Obwohl ich ihn mit double kompiliert habe, entspricht die ausgegebene 
Zahlenfolge der wie mit float - exakt!

Diesen Eindruck hatte ich schon mal, aber da habe ich es nicht näher 
untersucht.

Jetzt hab ich ein Testprogramm geschrieben.
Das bestätigt jedoch, dass double 64 bit hat.
Sehr seltsam, anscheinend habe ich in meiner Filter-Implementierung 
irgendwo etwas übersehen...

Hier die Ausgabe des Testprogramms:

Precision Test Program of floating point numbers:
float:
n=24
sizeof(x)=4

double:
n=53
sizeof(x)=8

Danke auf jedenfall erstmal.

lg, Karl

Autor: Karl Zeilhofer (griffin27)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
PS: wie kann man eine angehängte Datei wieder löschen?

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Karl Zeilhofer schrieb:

> Sehr seltsam, anscheinend habe ich in meiner Filter-Implementierung
> irgendwo etwas übersehen...

Wer Floating point Arithmetik naiv anwendet, wird immer wieder derartige 
Effekte erleben. Floating Point ist kein Allheilmittel für alles und 
jedes und erfordert extreme Sorgfalt.

Lies mal das hier
http://docs.sun.com/source/806-3568/ncg_goldberg.html

Wenn du willst konstruier ich dir auch ein Beispiel, welches obwohl alle 
Eingangszahlen exakt in Floating Point repräsentiert werden können (also 
keine Rundungsfehler bei den Ausgangswerten) und ein und dasselbe 
Verfahren symetrisch benutzt wird (einmal wird aus a b ausgerechnet, 
einmal aus b a, wobei exakt der gleiche Code benutzt wird), 
widersprüchliche Ergebnisse liefert :-) Floating Point ist manchmal 
nicht die Lösung, sondern das Problem.

Autor: Karl Zeilhofer (griffin27)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Karl heinz, danke für den Link.
Hab grad nicht die Zeit für dieses ausfühliche Dokument.

Mir ist sehr wohl bewusst, was bei Gleitkommazahlen passiert.

Mit
> Sehr seltsam, anscheinend habe ich in meiner Filter-Implementierung
> irgendwo etwas übersehen...
hab ich gemeint, dass ich beim kompilieren was übersehen haben muss.

So war es auch. Denn für den PC kompiliert erhielt ich unterschiedliche 
Ergebnisse für float und double - auf dem ARM auf einmal nicht.
Da ich aber nur ein typedef geändert habe, wurden die files die diese 
Definition verwenden nicht neu kompiliert. Ein "clear all" hat geholfen. 
Das war heute sowas wie eine selbsterfüllende Prophezeiung, da ich mir 
schon mal eingebildet habe, dass der arm-elf-gcc double wie float 
implementiert. Etwas peinlich, aber was solls.

Auf dein angesprochenes künstliches Problem bin ich aber neugierig.
Kannst du einen Code oder so posten?

Im Bild sieht man die "eingeschwungene Sprungantwort" des von mir 
implementierten Tiefpassfilters, der mit 2kHz Samplerate läuft und auf 
50Hz Grenzfrequenz ausgelegt wurde, also Omega_c = pi/20. Entworfen mit 
analogem Butterworth, 5. Ordnung und Bilinearer Transformation. Grausam, 
was Rundungsfehler anrichten können. Der Filter wird auf einmal zum 
Rauschgenerator.

Fixkommaberechnung (bzw. Ganzzahl-) kann aber vom Prinzip her auch nicht 
besser sein als Gleitkomma, oder?
Ich sehe es als das beste an, das uns für numerischer Probleme zur 
Verfügung steht, aber trotzdem hat alles seine Grenzen - und wenn die 
Mantisse noch so viele Bits hat.

lg, Karl

Autor: Andreas Ferber (aferber)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Karl Zeilhofer schrieb:
> Fixkommaberechnung (bzw. Ganzzahl-) kann aber vom Prinzip her auch nicht
> besser sein als Gleitkomma, oder?

Das kommt auf den benötigten Wertebereich an. Prinzipiell kann ein 
64bit-Fixkommawert bis ca. 3 signifikante Dezimalstellen mehr haben als 
ein IEEE-754-double. Ausserdem kann auf 32bit-Architekturen meist auch 
recht problemlos mit 128bit-Integern gearbeitet werden, das gibt dann 
nochmal erheblich mehr Stellen.

Andreas

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Karl Zeilhofer schrieb:

> Auf dein angesprochenes künstliches Problem bin ich aber neugierig.
> Kannst du einen Code oder so posten?

:-)

Das hab ich vor Jahren mal in comp.lang.c++ gepostet
For another example (taken from "Geometric and Solid Modeling, Christoph Hoffmann" ) 


Consider implementing a test of whether two points in the plane 
are equal. Specifically assume that the point u is the intersection 
of the pair of lines (L1,L2), and that the point v is the intersection 
of the lines (L3,L4). The line equations are the input to the following 
algorithm: 

Also zu deutsch:
Wir wollen wissen ob 2 Punkte identisch sind. Die beiden Punkte 
definieren sich dadurch, dass sie die Schnittpunkte von jeweils 2 
Geraden sind.

L1 und L2  definieren Punkt A
L3 und L4  definieren Punkt B

und wir wollen wissen, ob A identisch ist zu B (natürlich mit einem 
kleinen erlaubten Epsilon, wir sond ja brave Floating Point 
Programmierer)
1. Compute the coordinates of u. 
2. By substituting into the line equations L3 and L4, conclude that 
   u == v if both L3(u) and L4(u) are smaller then some tolerance. 

Dazu benutzen wir dieses Verfahren:

Für jeden Punkt auf einer Geraden gilt: Seine Koordinaten eingesetzt in 
die Geradengleichung ergeben 0 (natürlich erlauben wir eine kleine 
Toleranz, wann kommt bei einer Berechnung schon exakt 0 raus, wenn 0 
rauskommen sollte)

Wir machen daher:
  Berechne den Schnittpunkt A und setze ihn in L3 und L4 ein.
Punkt B wird gar nicht berechnet. Es ist aber klar dass A identisch zum 
nicht berechneten B sein muss, wenn A sowohl auf L3 als auch auf L4 
liegt. Denn es gibt immer nur 1 Punkt, der gleichzeitig auf 2 Geraden 
liegen kann, nämlich den Schnittpunkt der beiden Geraden.

Anstelle B explizit auszurechnen, genügt es also nachzusehen, ob A 
dieser Schnittpunkt wäre. Ausgedrückt dadurch, das A auf L3 als auch auf 
L4 liegen muss.

Clever Trick! Denn um einen Punkt in eine Geradengleichung einzusetzen 
muss man nicht viel rechnen. Für einen Schnittpunkt muss man aber 
vergleichsweise aufwändig  rumrechnen. So gesehen wäre dieses Verfahren 
viel einfacher!
Intuitively, this algorithm ought to be equivalent to a second version in 
which the roles of u and v are reversed. Lets see if this is true. 


(Hint: a1 denotes 'a' with a subcscript of 1) 


1. The intersectoin (ux, uy) of the lines 


          a1*x + b1*y + c1 = 0 
          a2*x + b2*y + c2 = 0 


   is computed as: 


         D = a1*b2 - a2*b1 
         ux = (b1*c2 - b2*c1) / D 
         uy = (a2*c1 - a1*c2) / D 


2. The point (ux,uy) is assumed to lie on the line a*x + b*y + c = 0
   if the distance is small; that is if
   |a * ux + b * uy + c| < eps * sqrt(a*a + b*b) 


We assume eps to be 1E-10, a reasonable bound for double precision. We
ask whether u and v are incident using 2 different methods: 

Jetzt fragen wir uns:
Wenn wir A ausrechnen und in L3 / L4 einsetzen UND da kommt raus, dass A 
auf L3 / L4 liegt, dann müsste doch eigentlich auch die Umkehrung 
gelten: Ich kann B ausrechnen und in L1 / L2 einsetzen. Muss das gleiche 
rauskommen!

Denn wenn A gleich B ist, dann darf es keine Rolle spielen, ob ich über 
A teste oder ob ich über B teste.

a. Compute the coordinates of u;
   conclude that u == v iff u is on both L3 and L4. 
b. Compute the coordinates of v;
   conclude that u == v iff v is on both L1 and L2. 

probiern wirs praktisch aus:
Man nehme 4 Geraden:
The line coefficients follow. Since pow(2,-23) ~ 1E-7, they differ
from 1 and 0 by amounts that are several orders of magnitude larger
then eps. 


a1 = -1                  b1 = 1               c1 = 0 
a2 = -(1+pow(2,-23))     b2 = 1-pow(2,-23)    c2 = pow(2,-22) 
a3 = 1                   b3 = 0               c3 = -(1+pow(2,-15)) 
a4 = 0                   b4 = 1               c4 = -(1+pow(2,-15)) 


These coefficients can be represented *exactly* in double precision.

Man beachte: Die Koeffizienten der Geradengleichungen sind so gewählt, 
dass sie (die Koeffizienten) exakt darstellbar sind. Da ist also keine 
Rundung im Spiel!
The coordinates of the points are now computed to be 


    u = ( 1.0, 1.0 ) 
    v = ( 1.000030517578125, 1.000030517578125) 


They are both exact.

und daqs sind die Koordinaten der jeweiligen Schnittpunkte A und B. 
Genaue Analyse zeigt, dass beide bis auf die letzte Kommastelle stimmen
 Moreover since ai*ai + bi*bi is aproximately between 
1 and 2, the evaluation of the line equations after substituting the point
coordinates yields an error that can be compared directly with eps. We
obtain the values 


    L3(u) ~ -3E-5      > eps 
    L4(u) ~ -3E-5      > eps 


from which we conclude that u connot be incident to v, since it is too
far from the lines L3, L4 whose intersection is v. 

Punkt A in L3/L4 eingesetzt zeigt, dass der Punkt fast, aber nicht genau 
genug auf L3 bzw L4 liegt. Die Schlussfolgerung daher: A liegt nicht auf 
L3/L4,  A ist daher nicht identisch zum Schnittpunkt L3/L4 (also B)
But we also obtain 


    L1(v) = 0          < eps 
    L2(v) ~ -7E-12     < eps 


from which we must conclude that v is incident to u, since it lies
extremely close to both lines. 

Aber aus Sicht von B sieht das ganz anders aus!
B liegt exakt auf L1 und nahe genug aus L2, sodas wir das nach als 
'liegt drauf' akzeptieren. AUs Sicht von B liegt B auf L1/L2 so dass 
sich hier gemäss Algorithmus ergibt: A ist identisch zu B
Therefore, although they ask the same geometric question, the two
computations yield contradictory results. 

Was denn nun? Sind A und B gleich oder sind sie es nicht?
Aus Sicht von A sind sie nicht gleich
Aus Sicht von B sind sie gleich

Ein Widerspruch!
So what can one do about this. 
Clearly: Don't use that algorithm. One could choose to do: 


1. Compute the coordinates of u and v, by intersecting the
   respective lines. 
2. If the euclidian distance between u and v is smaller then eps,
   decide u == v; 
   otherwise decide u != v 


(Note that this computation is more 'expensive' then the previous one.
This time both points and an euclidian distance needs to be computed.
In the previous algorithm only one point is computed and the testing
does not involve a square root.) 


This method is symetric, but it does not exhibit transitivity.
Specifically, we choose 3 points u, v and w such that u is incident
to v, v is incident to w, *but* u is not incident to w. We assume an
eps of 1E-10 


  u = ( 0, 0 )     v = ( 0, 0.8E-10)    w = ( 0, 1.6E-10 ) 


Clearly the distance between the adjacent pairs is less then eps, but
the distance between u and w is greater then eps. So what is the correct
answer? Are all those points equal or are they not? 


Der Artikel enthält 2 Beispiele, das 2.te ist ein wenig trivial, das 
erste ist aber der Hammer: Ein auf den ersten Blick Super Algorithmus 
(wegen Leufzeit einsparen) liefert verschiedene Antworten, je nachdem ob 
man
  f(x,y)
oder
  f(y,x)
berechnet, wobei f so "designed" ist, dass es eigentlich keine Rolle 
spielen sollte, welche Argumente man benutzt.



http://groups.google.de/group/comp.lang.c++/browse...

ganz unten, der letzte Post

Autor: Karl Zeilhofer (griffin27)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nettes Beispiel!

@Andreas: 128 Bit Integer, die der Kompiler direkt unterstützt, ohne 
Rechen-Funktionen/-Makros?? Wie geht das? long long int ist nämlich als 
64 Bit Integer definiert (beim arm-elf-gcc).

@Martin Thomas: Das mit Code Sourcery ist mir ganz was neues.
Das muss ich mir bei Zeiten mal zu gemüte führen.
Worin genau bestehen die Vorteile? Wenn eine Toolchain mal läuft, bin 
ich doch schon glücklich. Brauch ich da ständige Updates, wo ich wieder 
vieles umkrempeln muss (oder ist das nicht der Fall)?

lg, Karl

Autor: Martin Thomas (mthomas) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Karl Zeilhofer schrieb:
>...
> @Martin Thomas: Das mit Code Sourcery ist mir ganz was neues.
> Das muss ich mir bei Zeiten mal zu gemüte führen.
> Worin genau bestehen die Vorteile?

Der m.M. nach größte Vorteil ist, dass die Leute von Codesourcery sehr 
gut über die GNU Toolchain Bescheid wissen. Wenn man sich die 
Änderungshistorie der Quellcodes für GNU binutils und GNU GCC anschaut, 
tauchen sehr oft die Namen von Codesourcery Mitarbeitern auf. Verwundert 
wenig, da m.W. CS von ARM dafür bezahlt wird, sich um die GNU Tools zu 
kümmern. Falls nötig, kann man sich bei CS auch Support kaufen. Etwas 
kostenlosen Support gibt es auch in einem Forum bei Codesourcery. Die 
GNU Toolchain hinter Crossworks ist meines Wissens auch die Fassung von 
CS. Bei einigen Anbietern findet man auch Beispielcode, der mit der CS 
Toolchain getestet wurde (z.B. TI/LMI)

Nennenswerte technische Vorteile im Vergleich zu anderen vokompilierten 
Toolchains für MS Windows Hosts kenne ich keine mehr. Vor Jahren war die 
Unterstützung von ARMv7/thumb2/Cortex-M3 nur bei Codesourcery zu haben, 
inzwischen ist diese aber auch in den offiziellen GNU Quellcodes 
enthalten. Nachdem auch Yagarto nun für arm-eabi Target gebaut wird, 
gibt es auch "unter der Haube" keine mir bekannten nenneswerten 
Unterschiede mehr dazu. DevkitARM enthält noch ein paar zusätzliche 
Dateien für die Eigenentwicklung von Anwendungen für Spielkonsolen (z.B. 
GBA), diese Dateien kann man aber auch bei anderen Toolchains 
nachrüsten. Pflege des GNUARM Packets ist meines Wissens inzwischen 
eingestellt. WinARM liegt wie oben geschrieben auf Eis. Andere GNU 
Packete habe ich nie genutzt.

Nachteil ist, das Codesourcery manchmal etwas hinterherhinkt mit der 
Lite-Version (kommerzielle Version ist mglw. aktueller - kenne ich aber 
nicht). Habe als Begründung gelesen, dass man bei CS viele eigene 
Testläufte durchführt, bevor man ein Packet freigibt. Wahrscheinlich 
(=Spekulation) will man aber einfach lieber ein Packet mit Support 
verkaufen und bietet als Anreiz dafür häufigere Aktualisierung als bei 
dem kostenlosen Lite Packet. Yagarto und DevkitARM sind manchmal mit 
aktuellerem Quellcode erstellt.

> Wenn eine Toolchain mal läuft, bin
> ich doch schon glücklich.
Ist ja auch o.k. Ich kenne einige, die an alten Toolchain-Versionen 
festhalten. Manchmal weil man Anwendungen damit ausgiebig getestet hat 
und nicht nochmal von Neuem testen mag. Manchmal einfach weil man 
glaubt, alle Fehler in einer alten Version zu kennen und weiss, wie man 
sie umgehen kann. Falls es aber hart auf hart kommt, wird man kaum auf 
Unterstützung für eine alte Version hoffen dürfen, weder bei den 
Kommerziellen noch bei "der Community".

> Brauch ich da ständige Updates, wo ich wieder
> vieles umkrempeln muss (oder ist das nicht der Fall)?
Ständige Updates braucht man sicher nicht aber auch nicht zu lange 
hinterherhängen, sonst gibt es umso mehr Verdruss, falls man updaten 
muss, z.B. weil ein verwendeter Core nur von einer neuen Version der 
Tools untersützt wird. Ich hatte aber nach Updates von CS G++ lite seit 
vielen Versionen keine Probleme. Es kann aber durchaus sein, dass Fehler 
im Quellcode erst dann auffallen, wenn nach einem Update eine neuere 
Compilerversion mit besserer Optimierung genutzt wird. Häufig ist dann 
z.B. ein fehlendes volatile Ursache für ein Fehlverhalten. Man kann das 
dann nicht der neuen Version anlasten und viel "Umkrempeln" muss man für 
die Korrektur solcher Fehler nicht.

Falls man älteren Quellcode für arm-elf hat, kann es beim Update auf 
eine arm-eabi Toolchain vorkommen, dass die Attribute für ISRs nicht wie 
erwartet funktionieren. Diese Attribute sind ohnehin für viel Verdruss 
verantwortwortlich. APCS-Frame Compiler switch hat bei mir und Leuten, 
die mich gefrage haben bisher geholften, um auch Code mit diesen 
Attributen zum Laufen zu bringen. Ob das immer hilft, weiss ich nicht. 
Mittel der Wahl z.B. bei ARM7TDMI ist m.M. auf die Attribute zu 
verzichten und einen Assembler-Wrapper für IRQs zu verwenden. Kosten ein 
paar Zyklen aber verhindert mehr als ein paar graue Haare. Atmel zeigt 
in seien Beispielcodes ja, wie man dass für AT91SAM7 mit ARM7TDMI und 
AIC implementieren kann. Falls man das schon so gemacht hat, ist beim 
Toolchain-Update diesbezüglich kein Problem zu erwarten.

Hoffe, dieser längliche Text hilft etwas weiter.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Karl Zeilhofer schrieb:

> @Andreas: 128 Bit Integer, die der Kompiler direkt unterstützt, ohne
> Rechen-Funktionen/-Makros?? Wie geht das? long long int ist nämlich als
> 64 Bit Integer definiert (beim arm-elf-gcc).

Bloss weil ein Compiler keinen Datentyp für 128 Bits hat musst du nicht 
zwangsläufig drauf verzichten. Kann man sich programmieren. Und wenn man 
C++ verwendet, dann merkt man das hinterher nicht einmal, jedenfalls 
nicht im Quelltext. So richtig brandschnell ist das ohne 128-Bit 
Maschine natürlich nicht.

Autor: Andreas Ferber (aferber)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Karl Zeilhofer schrieb:
> @Andreas: 128 Bit Integer, die der Kompiler direkt unterstützt, ohne
> Rechen-Funktionen/-Makros?? Wie geht das? long long int ist nämlich als
> 64 Bit Integer definiert (beim arm-elf-gcc).

Aus kleineren Datentypen selbst bauen. Addition und Subtraktion sind 
trivial, Multiplikation erfordert geringfügig mehr nachdenken, einzig 
Division wird ein bisschen kniffliger, aber auch noch überschaubar. 
Einfach mal an das in der Schule praktizierte schriftliche Rechnen 
zurückdenken.

Grössere Fliesskomma-Typen von Hand zu bauen ist dagegen deutlich 
komplizierter.

Andreas

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.