Float anschauen

[Peter Z. (Gast)]

Hallo, ich möchte mir die innere Zahlendarstellung von float und 
double anschauen.

(Mein ATtiny84 kennt kein printf, ich habe nur ein kleines LC-Display)
Wie kann ich eine float absichtlich falsch in eine unsigned long 
Variable casten, um mir das in HEX anzeigen zu lassen?

[Einsteiger (Gast)]

Du könntest ein memcpy machen und die Bytes mit printf (%x) ausgeben.

Grüsse,
René

[Dr. Sommer (Gast)]

uint32_t converted = *((uint32_t*) &someFloat);

[Klaus W. (mfgkw)]

und die dritte Standardmöglichkeit der Vollständigkeit halber:
eine union basteln mit einer float und einer uint32_t, dann an die float 
zuweisen und aus der uint32_t entnehmen.

[Johann L. (gjlayde)]

Standardkonform ist die Verwendung von memcpy.  Weder die 2. noch der 3. 
Vorschlag sind standardkonform, wobei die Verwendung einer Union wie im 
Vorpost mit GCC funktioniert, aber nicht unbedingt mit anderen 
(standardkonformen) Compilern.

[Dr. Sommer (Gast)]

casten und unions sind beide standardkonform, aber genau wie memcpy sind 
sie alle undefined behaviour. Das ergibt sich allein schon daraus dass C 
den Aufbau von floats nicht definiert. Sie sollten aber "zufällig" im 
GCC funktionieren...
Und falls der Compiler das memcpy nicht wegoptimiert kriegt ist das 
außerdem extrem ineffizient.

[Johann L. (gjlayde)]

Dann lies mal nach über Strict Aliasing bevor du hier Tipps gibst.

[Rolf Magnus (Gast)]

Dr. Sommer schrieb:
> casten und unions sind beide standardkonform, aber genau wie memcpy sind
> sie alle undefined behaviour. Das ergibt sich allein schon daraus dass C
> den Aufbau von floats nicht definiert.

Der Aufbau von float und der Aufbau von unsigned long. Erst die 
Kombination der beiden macht es undefiniert. Laut ISO C ist es nämlich 
durchaus erlaubt, ein beliebiges Objekt, also auch einen float, per 
memcpy in ein Array aus unsigned char zu kopieren, um auf diese Weise 
die Byte-Repräsentation zu bekommen.

> Und falls der Compiler das memcpy nicht wegoptimiert kriegt ist das
> außerdem extrem ineffizient.

Dann ist aber auch der Compiler extremer Murks.
gcc muß es noch nicht mal wegoptimieren, da es eh komplett im Compiler 
implementiert ist. Das heißt, daß es selbst bei ganz ausgeschalteten 
Optimierungen nicht zu einem Funktionsaufruf kommt.

Ich habe mal folgende 3 Varianten verglichen:

static inline unsigned long a(float f)
{
    return *(unsigned long*)&f;
}

static inline unsigned long b(float f)
{
    unsigned long ret;
    memcpy(&ret, &f, sizeof ret);
    return ret;
}

static inline unsigned long c(float f)
{
    union
    {
        float f;
        unsigned long u;
    } uf;

    uf.f = f;
    return uf.u;
}

Auf avr-gcc mit -O3 kommt bei allen drei exakt das gleiche raus. Bei dem 
für x86-64 ist die union-Variante eine Instruktion länger. Alles andere 
ist aber auch da gleich.
Was man hier aber schon sieht, ist daß vom Source-Code her die 
union-Variante irgendwie nach "von hinten durch die Brust in Auge" 
aussieht.