Double=16Bit?

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

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

>...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.

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.

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