Hallo, ich habe eine Frage zum Datentyp Double. Irgendwie habe ich früher angenommen, dass Double 16 Bit lang ist. Aber jetzt lese ich, dass double irgendwie 64 Bit lang sind! Warum funktioniert dann meine TWI-Kommunikation, indem ich 16 Bit versende und empfange und die Zahlen sind korrekt!
Noch viel schlimmer: double ist ein Fliesskomma-Format, das kann ein uC nur mit sehr viel Aufwand rechnen. Stichwort: Zahlenformate >Warum funktioniert dann meine TWI-Kommunikation, indem ich 16 Bit versende >und empfange und die Zahlen sind korrekt! vermutlich ein paar impilzite casts? Stichworte: casten von char, sort, long, int, float, double Das ist ja wie Autofahren und nicht wissen, wo der Blinker ist. (Ja klar gehts auch ohne....sehen wir ja)
Wenn in einem 8-bit Kontext programmiert wird sind 16-bittige Doubles üblich. Bei einem 32-bit-System sinds dann eben 64-bit für ein Double. bye Frank
>Stichworte: casten von char, sort, long, int, float, double
Nochmal:
Stichworte: casten von char, short, long, int, float, double
>...16-bittige Doubles üblich...
Von welcher Programmiersprache reden wir denn eigentlich?
Long double ist mitunter 16 lang, dann aber 16 Bytes. Normaler double immer 8 Bytes, außer im fehlerhaften gcc für avrs (da isser 4 byte und erfüllt damit ganz sicher nicht die vorgeschriebene Rechengenauigkeit für double).
I_ H. wrote: > Long double ist mitunter 16 lang, dann aber 16 Bytes. Normaler double > immer 8 Bytes, außer im fehlerhaften gcc für avrs (da isser 4 byte und > erfüllt damit ganz sicher nicht die vorgeschriebene Rechengenauigkeit > für double). AVR-GCC hat nie C99-Konformität für sich geltend gemacht. Die Erfordernis, dass ein double effektiv mit mehr als 32 Bits implementiert werden muss, um standardkonform zu sein, ist übrigens erst kurz vor der Verabschiedung von C99 in den Standard aufgenommen worden. In den teilweise noch im Netz kursierenden Standard- Entwürfen für C99 war die Formulierung noch so, dass sie mit 32 Bits erfüllbar gewesen wären. 32-bit-Gleitkommazahlen sind für die meisten AVR-Nutzer ein günstiger und sinnvoller Kompromiss, auch wenn er nicht mit C99 konform geht. Das Problem ist ja weniger, ob man sich die Größe mittels float oder double selbst aussuchen kann, sondern vielmehr die floating-point promotion rules, die es erfordern, dass intern alle Gleitkomma- Ausdrücke mit `double' gerechnet werden müssen bzw. so, ,,als ob'' sie dies wären -- aber sinnvolle durch den Compiler realisierbare Abkürzungen wie bei integer-Datentypen gibt es bei Gleitkomma eher nicht (von Operationan mit Konstanten abgesehen). Nichtdestotrotz hätte ich gern jemanden, der eine 64-bit-Gleitkomma- Implementierung für den AVR-GCC mal angeht. Dann könnte man es so aufbauen, dass man (ähnlich wie mit der -mint8-Option) zwischen voller C99-Konformität und dem jetzigen Kompromiss per Option auswählen kann (vielleicht -mdouble32). `long double' kann ja dann in jedem Falle als 64-Bit-Typ implementiert werden. Der Standard schreibt übrigens nirgends Bitlängen vor, nur Genauig- keiten, und die Forderung für double wäre wohl auch mit 48 Bits gut zu erfüllen. Allerdings kennt der GCC kein derartiges Format.
Jörg Wunsch wrote: > worden. In den teilweise noch im Netz kursierenden Standard- > Entwürfen für C99 war die Formulierung noch so, dass sie mit 32 Bits > erfüllbar gewesen wären. Im Ernst? Damit wäre C99 ja schwächer als C89 gewesen.
Ist eigentlich Double vorzeichenbehaftet? Kann man negative und positive Zahlen damit darstellen?
Boxer wrote: > Ist eigentlich Double vorzeichenbehaftet? Kann man negative und positive > Zahlen damit darstellen? http://www.gidf.de
Jörg Wunsch wrote: > Nichtdestotrotz hätte ich gern jemanden, der eine 64-bit-Gleitkomma- > Implementierung für den AVR-GCC mal angeht. Es würde auch schon viel helfen, die 4 Grundrechenarten als 64Bit einzubinden (<200 Byte). Theoretisch ist zwar long long implementiert, aber mit etwa 5kB sogar noch aufwendiger als float, also praktisch nicht nutzbar. Peter
Peter Dannegger wrote: >> Nichtdestotrotz hätte ich gern jemanden, der eine 64-bit-Gleitkomma- >> Implementierung für den AVR-GCC mal angeht. > > Es würde auch schon viel helfen, die 4 Grundrechenarten als 64Bit > einzubinden (<200 Byte). Ist ein getrenntes Paar Schuhe, aber: ja, mach doch! > Theoretisch ist zwar long long implementiert, aber mit etwa 5kB sogar > noch aufwendiger als float, also praktisch nicht nutzbar. Naja, der ATmega128 ist ja nun auch nicht gerade vorgestern erfunden worden... Aber das ist schon klar, soweit ich weiß, ist das einfach nur automatisch (und generisch) generierter Code in der libgcc.a. Da müsste stattdessen jemand handoptimierten Code und/oder die entsprechenden insns gleich inline schreiben. Das Problem ist wie immer: es muss sich jemand finden, der es tut. Nur darüber zu reden hilft nicht viel... Und nein, meine eigenen Zeitreserven sind nahe Null.
Jörg Wunsch wrote: > Nichtdestotrotz hätte ich gern jemanden, der eine 64-bit-Gleitkomma- > Implementierung für den AVR-GCC mal angeht. Ich habe das mal angegangen: http://www.martin-cibulski.de/atm/mount_controller_4/mc_4_asm_main/index_de.htm Ich hätte gern jemanden, der die Assemblerroutinen in die C-Library einbindet . . . Gruß, Martin Cibulski
Der Haken hier ist, dass man das (sinnvoller Weise) nicht allein auf der Bibliotheksebene lösen kann, sondern dass man als erstes mal dem Compiler beibringen muss, 64-bit-FPs zu bearbeiten. Die eigentlichen Rechenoperationen liegen dann schon in Bibliotheksfunktionen, aber auch diese gehören in die libgcc.a, da der Compiler auch ohne die Hilfe einer Standardbibliothek in der Lage sein muss, die normalen Rechenoperationen auszuführen. Die avr-libc kommt erst für die Dinge ins Spiel, die in <math.h> beschrieben werden (Winkelfunktionen etc.). Damit das Ganze Sinn hat, muss man leider auch den leidigen Bürokratie- kram der GNU-Leute erledigen (die möchten partout das Copyright an die FSF abgetreten haben, auch wenn eine derartige Aktion für uns Deutsche kompletter Nonsense und juristisch null und nichtig ist). Alles Andere hat in meinen Augen nicht viel Sinn, da es zu umständlich zu benutzen ist. Man möchte ja in seinem C-Code schreiben können
1 | const double pi = 3.141592653589793238462643383279502884197; |
2 | ...
|
3 | x = asin(a / 180.0 * pi); |
und nicht
1 | typedef uint8_t[8] mydouble; |
2 | |
3 | /* PI */
|
4 | dconst(mydouble, 0x18, 0x2d, 0x44, 0x54, 0xfb, 0x21, 0x09, 0x40); |
5 | ...
|
Jörg Wunsch wrote: >> Es würde auch schon viel helfen, die 4 Grundrechenarten als 64Bit >> einzubinden (<200 Byte). > > Ist ein getrenntes Paar Schuhe, aber: ja, mach doch! Genau das ist mein Problem, ich hab null Ahnung, wie man die fertigen Assemblerroutinen in einen C-Compiler integriert bzw. wie man überhaupt nen Compiler compiliert. > Naja, der ATmega128 ist ja nun auch nicht gerade vorgestern erfunden > worden... Naja, auch der große AVR ändert aber nichts daran, daß der große Code auch viel langsamer ausgeführt wird, als die kleine Assemblerroutine. Und wenn ich nur 16 IOs brauche, setze ich ungern nen Tausendfüßler ein. Peter
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.