www.mikrocontroller.net

Forum: Compiler & IDEs Double=16Bit?


Autor: Boxer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!

Autor: holger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das liegt an dem Programm das nur du kennst ;)

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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)

Autor: Frank L. (hermastersvoice)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Stichworte: casten von char, sort, long, int, float, double
Nochmal:
Stichworte: casten von char, short, long, int, float, double

Autor: Andreas K. (a-k)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Frank: Was soll den dass jetzt werden? Für Jux ist es nicht witzig 
genug.

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>...16-bittige Doubles üblich...
Von welcher Programmiersprache reden wir denn eigentlich?

Autor: Boxer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich programmiere in C in AVRStudio für Atmega 8-Bit Mikrocontroller.

Autor: I_ H. (i_h)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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).

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

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Andreas K. (a-k)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Boxer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ist eigentlich Double vorzeichenbehaftet? Kann man negative und positive 
Zahlen damit darstellen?

Autor: Johannes M. (johnny-m)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Boxer wrote:
> Ist eigentlich Double vorzeichenbehaftet? Kann man negative und positive
> Zahlen damit darstellen?
http://www.gidf.de

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

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

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Martin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Ich hätte gern jemanden, der die Assemblerroutinen in die C-Library 
einbindet . . .

Gruß,
Martin Cibulski

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

Bewertung
0 lesenswert
nicht lesenswert
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
const double pi = 3.141592653589793238462643383279502884197;
...
x = asin(a / 180.0 * pi);

und nicht
typedef uint8_t[8] mydouble;

/* PI */
dconst(mydouble, 0x18, 0x2d, 0x44, 0x54, 0xfb, 0x21, 0x09, 0x40);
...

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

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.