unions structs bildfields

Die Bits stapelt der Compiler so zusammen, wie sie eintreffen. Wichtig 
ist nur, das ganze PACKED zu machen, damit dir da kein Padding in die 
Quere kommt. Und auf LE/BE achten, falls notwendig, da hilft auf dem 
Cortex-M der REVSH.

Random .. schrieb:
> Und auf LE/BE achten, falls notwendig, da hilft auf dem
> Cortex-M der REVSH.

OP schrieb nix von einem Cortex-M.

Und ich habe bei 8-Bit Compilern schon gesehen das die Hersteller sich 
nicht über Big oder Little Endian auf einer Plattform einig waren.

OP hätte schreiben sollen wo der Code überall laufen muss, davon hängt 
ab wie aufwändig man die (De-) Serialisierung macht.

unions structs bildfields schrieb:
> Ich habe irgendwie im hinterkopf, dass es irgendwie compiler abhängig
> sein könnte wie die bit reihenfolge, das alignment der structur
> gespeichert wird.

Korrekt. In C++ ist es sogar komplett verboten. Siehe Serialisierung 
und meine Bibliothek welche dieses Problem löst: 
https://github.com/Erlkoenig90/uSer

Frickel schrieb:
> Um mal über den Tellerrand zu schauen

Stimmt, aber das Hauptproblem von C und C++ ist hier, dass Fehler dieser 
Art noch sehr oft falsch beigebracht werden, auch von Büchern und 
Kursen. Allein die Tatsache dass hier im Forum bei solchen Fragen immer 
sofort der Begriff "union" fällt spricht Bände...

Niklas Gürtler schrieb:
> A. S. schrieb:
>> Keine union: stattdessen memcpy, byte-ptr oder einzeln aufdröseln
>
> memcpy und Pointer sind genau so Plattform/Compiler abhängig.

Aber es ist weniger umständlich und missbraucht nicht ein Sprachfeature, 
das dafür eigentlich gar nicht gedacht war.

soviet union schrieb:
> So, ich habe mal "gegoogelt".
>
> Die Datentypen uint8_t / int8_t kann es auf einer Platform zwar geben,
> muss es aber nicht. Wenn es sie gibt, dann ist sizeof(char) == 1 Byte.

sizeof(char) ist immer 1 Byte, egal ob es uint8_t gibt oder nicht. 
Ansonsten soweit richtig.

> Tja, damit ist jeder Code, der uint8_t benutzt "implemantation defined".

Wenn man davon ausgeht, Datentypen mit einer ganz bestimmten Größe 
vorzufinden, ist das immer implementation-defined.

> Es ist also nicht sehr sinnvoll  uint8_t nutzen und beim char*-Zeiger
> den Zeigefinger erheben.

Es gibt da schon einen Unterschied. char muss nicht exakt 8 Bit breit 
sein, uint8_t aber schon. Wenn ich also auf einer Plattform, die keinen 
8-Bit-Typen kennt, char verwende und dabei voraussetze, dass der exakt 8 
Bit breit ist, kommt dabei ein Programm raus, das Blödsinn macht. Nehme 
ich uint8_t, dann bricht der Compiler mit Fehler ab, da der benötigte 
Typ nicht existiert. Außerdem dokumentiert es den Code besser, wenn 
durch uint8_t klar gemacht wird, dass hier ganz speziell ein exakt 8 Bit 
breiter Datentyp gefordert ist.

A. S. schrieb:
> Es ist aber explizit erlaubt, mit einem byteptr und sizeof(Struktur) die
> komplette Struktur in Bytes zu zerlegen.

Allerdings nur per memcpy, nicht per einfachem Pointer-cast.

Niklas Gürtler schrieb:
> Olaf schrieb:
>> In aller Regel klappt es aber
>
> Bei wie viel Prozent der Plattformen reicht es? Zwischen AVR und ARM ist
> es schon nicht übertragbar. Und das "packed" Attribut ist Gift für die
> Performance auf 32 bit Plattformen.

Je nach Plattform kann es auch sein, dass ein Zigriff mit falschem 
Alignment gar nicht unterstützt wird und das Programm z.B. mit einer 
Hardware-Exception abgebrochen wird.

Rolf M. schrieb:
> Je nach Plattform kann es auch sein, dass ein Zigriff mit falschem
> Alignment gar nicht unterstützt wird und das Programm z.B. mit einer
> Hardware-Exception abgebrochen wird.

Dafür gibt es im GCC das "-munaligned-access" -Flag - ist es gesetzt, 
wird angenommen die Hardware kann solche unaligned Zugriffe, und wenn 
sie es doch nicht kann, gibt es eine Exception. Ist das Flag nicht 
gesetzt, werden die Zugriffe über einzelne Byte-Zugriffe umgesetzt, die 
dann besonders langsam sind. So oder so ist "packed" langsam und keine 
echte Lösung.

Niklas G. schrieb:
> Rolf M. schrieb:
>> Je nach Plattform kann es auch sein, dass ein Zigriff mit falschem
>> Alignment gar nicht unterstützt wird und das Programm z.B. mit einer
>> Hardware-Exception abgebrochen wird.
>
> Dafür gibt es im GCC das "-munaligned-access" -Flag - ist es gesetzt,
> wird angenommen die Hardware kann solche unaligned Zugriffe, und wenn
> sie es doch nicht kann, gibt es eine Exception. Ist das Flag /nicht/
> gesetzt, werden die Zugriffe über einzelne Byte-Zugriffe umgesetzt, die
> dann besonders langsam sind. So oder so ist "packed" langsam und keine
> echte Lösung.

Offtopic:
An jener Stelle sei erwähnt dass dieses Flag automatisch gesetzt wird 
wenn die entsprechende Architektur übergeben wird, sprich etwa 
-march=armv7e-m. Man muss sich nicht selbst "händisch" darum kümmern ob 
die Architektur unaligned Zugriffe unterstützt oder nicht.

Olaf schrieb:
> Hab ich bisher zwischen diversen ARMs, SH2, 68000, PC(Qt), 68332 und
> M16C erfolgreich genutzt.

Hast du auch geprüft wie viel langsamer die "packed" Zugriffe sind?

Olaf schrieb:
> Wieso definierst du etwas dummes

Wo habe ich eine Definition gegeben?

Olaf schrieb:
> Merkt man dann ja gleich
> beim allerersten Test oder?

Nö. Bei manchen Plattformen (Cortex-M0?) passiert gar nichts, es wird 
nur Murks gelesen. Du merkst dann irgendwann dass du falsche Daten hast.

Olaf schrieb:
> Man muss vielleicht also mal sein Hirn
> einschalten. Ansonsten ist es euer geringstes Problem. Einfach mal
> ausprobieren...

Auch ein Problem von C - es erzeugt eine Art kognitive Dissonanz. In C 
gibt es eine Reihe an Dingen wie "union", die man zweckentfremden kann 
und die dann den Anschein geben, zu funktionieren. Das installiert sich 
dann im Gehirn als "SO macht man das", auch wenn es falsch ist. Wenn man 
dann darauf hingewiesen wird, dass es problematisch ist, und dass die 
korrekte Lösung eigentlich ganz einfach wäre, kommen Beleidigungen und 
"in 90% der Fälle funktioniert es" um auf jeden Fall die alt-bekannten 
falschen Wege zu rechtfertigen.

Olaf schrieb:
>> Je nach Plattform kann es auch sein, dass ein Zigriff mit falschem
>> Alignment gar nicht unterstützt wird und das Programm z.B. mit einer
>> Hardware-Exception abgebrochen wird.
>
> Hier noch nicht passiert. Aber ist ja super. Merkt man dann ja gleich
> beim allerersten Test oder?

Ja, sofern tatsächlich eine Exception kommt und nicht wie z.B. oben von 
Vincent erklärt der Compiler jeden Zugriff im Hintergrund automatisch 
über Zusammenstückelung einzelner Bytes umsetzt.

mh schrieb:
> Rolf M. schrieb:
>> A. S. schrieb:
>>> Es ist aber explizit erlaubt, mit einem byteptr und sizeof(Struktur) die
>>> komplette Struktur in Bytes zu zerlegen.
>>
>> Allerdings nur per memcpy, nicht per einfachem Pointer-cast.
>
> Mit einem Char-Pointer auf die Bytes der Struktur zugreifen ist erlaubt.

Sie per memcpy in ein Array aus unsigned char kopieren und dann auf 
dieses zugreifen, ist erlaubt. Das wird ausdrücklich genannt:

"Values stored in non-bit-field objects of any other object type consist 
of n×CHAR_BIT bits, where n is the size of an object of that type, in 
bytes.  The value may be copied into an object of type unsigned 
char[n](e.g., by memcpy); the resulting set of bytes is called the 
object representation of the value."

Ich wüsste keine Passage, die es explizit erlaubt, auch direkt auf die 
Bytes des Objekts als Array aus char zuzugreifen.

Rolf M. schrieb:
> Ich wüsste keine Passage, die es explizit erlaubt, auch direkt auf die
> Bytes des Objekts als Array aus char zuzugreifen.

Die Passage weiß ich gerade nicht, aber es ist definitiv erlaubt. Genau 
das macht memcpy auch, und memcpy ist an sich nichts besonderes, das 
kann man sich auch selbst implementieren über char-Pointer. Die 
C-Library hat nur meistens eine für die Plattform handoptimierte 
Version.

Ist aber egal, denn das Ergebnis ist natürlich auch implementation 
defined.

mh schrieb:
> — a character type.

Ok, überredet. :)

mh schrieb:
> Man könnte also sagen, ein Programm das memcpy nutzt ist
> implementation-definded, da string.h nicht aufgelistet ist.

Aber nur wenn es sich um eine freestanding implementation handelt. 
Soweit ich weiß, sind avr-gcc und ein Großteil der ARM-Toolchains als 
hosted implementation ausgelegt.

Stefan schrieb:
> Hast Du da weitergehende Informationen? Ich habe nichts zu
> Implementierungsabhängigkeit von Sign-Extensions finden können?

https://stackoverflow.com/a/7636 und im C-Standard¹, S. 85:

The result of E1 >> E2 is E1 right-shifted E2 bit positions. If E1 has 
an unsigned type or if E1 has a signed type and a nonnegative value, the 
value of the result is the integral part of the quotient of E1 / 2^E2. 
If E1 has a signed type and a negative value, the resulting value is 
implementation-defined.

Bei manchen Plattformen macht der Compiler halt eine Sign-Extension, und 
bei anderen nicht. Das hängt typischerweise davon ab, was der Prozessor 
am Besten kann.

Stefan schrieb:
> das lässt sich doch mit den 16 Bit
> darstellen:
>   10000000 00000000

Richtig. Und wenn man das als signed Integer in C nach rechts shiftet, 
wird die 1 entweder nur verschoben oder kopiert. Diese Zahl 3 bits 
nach rechts shiften kann als Ergebnis 00010000 00000000 oder auch 
11110000 00000000 haben. Der C-Standard legt das nicht fest.

Stefan schrieb:
> Oder bedeutet Sign-Extension, dass der Compiler/die Plattform aus
> irgendwelchen Gründen evtl. intern gar keine 16-Bit-Integer kennt und
> intern z.B. immer mit 32 Bit rechnet?

Nö, das ist nochmal was anderes.

1: http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf

mh schrieb:
> Rolf M. schrieb:
>> Aber nur wenn es sich um eine freestanding implementation handelt.
>> Soweit ich weiß, sind avr-gcc und ein Großteil der ARM-Toolchains als
>> hosted implementation ausgelegt.
> 5.1.2.2.2 Program execution
> In a hosted environment, a program may use all the functions, macros,
> type definitions, and objects described in the library clause (clause
> 7).
>
> Man kann mit dem avr-gcc alles nutzen, was in "clause 7" steht?

Ob er (bzw. die avr-libc) das vollständig untestützt, kann ich nicht 
sagen. Ich vermute mal, nicht. Aber zumindest wird gcc per Default im 
"hosted"-Modus betrieben. Ohne den würde er keine Optimierung der 
Standard-Funktionen wie eben gerade memcpy machen, da er nicht mehr 
annehmen kann, dass sie sich gemäß Standard verhalten.

Stefan schrieb:
> D.h. die Variante 11110000 00000000 ist mit Sign-Extension (weil die
> Zweierkomplement-Zahl praktisch von links mit Einsen negativ erweitert
> wurde) und 00010000 00000000 ohne, richtig?

Ja. Sign Extension bedeutet praktisch dass man das ganz linke Bit (das 
Sign Bit) kopiert.

Stefan schrieb:
> Ist das für einen Standard nicht etwas dünn?

Die C- und C++-Standards sind halt so definiert, dass die Sprache auf 
einer größtmöglichen Anzahl an Plattformen effizient lauffähig ist. 
Daher werden den Compilern viele Freiheiten gelassen. Es wird ja nicht 
einmal gefordert, dass 8-Bit-Bytes zur Verfügung stehen, denn char kann 
auch größer sein. Sprachen mit sehr fixen Regeln wie Java sind auf 
exotischeren Plattformen kaum lauffähig; auf einem DSP der nur 
36bit-Integer kennt müsste Java jede einzelne "short" oder "int" 
Operation aufwendig emulieren. Selbst auf AMD64 passt Java nicht so 
richtig, da Array-Größen & Indices 32bit sind. C und C++ haben da 
hingegen keine Probleme, da wird size_t einfach als 64bit definiert.

Allerdings sind selbst diese Freiheiten nicht immer ausreichend; auf AVR 
oder 8051 lässt sich C auch nicht 100% korrekt abbilden und man braucht 
Krücken wie "PROGMEM" oder "__flash".

Stefan schrieb:
> Wo liest man denn da Deine
> beiden o.g. Varianten heraus (Sign-Extension wird ja auch überhaupt
> nicht erwähnt)?

Die Varianten sind nicht vorgeschrieben. Die Plattform kann irgendwas 
tun. Die genannten Varianten sind nur die m.W. tatsächlich 
existierenden. Das 2er-Komplement ist ja auch nicht vorgegeben, die 
Plattform kann etwas anderes nutzen.

Stefan schrieb:
> Das ist übrigens auf Seite 95 statt 85 (falls noch jemand anderes
> nachschauen will)

Unten auf der Seite steht 85. Es ist nur PDF-Seite 97 (!).

Stefan schrieb:
> D.h. die Variante 11110000 00000000 ist mit Sign-Extension (weil die
> Zweierkomplement-Zahl praktisch von links mit Einsen negativ erweitert
> wurde) und 00010000 00000000 ohne, richtig?

Ja.

> Niklas G. schrieb:
>> If E1 has a signed type and a negative value, the resulting value is
>> implementation-defined.
>
> Ist das für einen Standard nicht etwas dünn?

Das Problem ist eben, dass nicht jede Hardware das direkt untersützt. 
Der Standard lässt dem Compiler die Wahl, damit der keine unnötig 
ineffizienten Verrenkungen anstellen muss, um ein vom Standard 
vorgeschriebenes Verhalten umzusetzen. So etwas gibt es in C an vielen 
Stellen, damit eine sinnvolle Implementation der Sprache für nahezu jede 
erdenkliche Plattform möglich ist.

> Wo liest man denn da Deine beiden o.g. Varianten heraus (Sign-Extension
> wird ja auch überhaupt nicht erwähnt)?

implementation-defined heißt nur, dass der Compiler es definieren muss. 
Mit und ohne Sign-Extension sind halt in der Praxis die gängigsten 
Varianten. Im Prinzip darf der Compiler es aber machen, wie er will, 
solange das Verhalten für positive Werte korrekt ist und für negative 
Werte reproduzierbar und im Handbuch des Compilers dokumentiert ist.

> mh schrieb:
>> Auf einer Plattform mit 16bit 2er Komplement int, ist "-32768" ein long.
>> Das "-" ist kein Teil des Literals.
> Habe ich jetzt nicht verstanden.

Es wird zuerst nur die 32768 betrachtet. Die passt nicht in einen 
16-Bit-int, also muss ein long draus gemacht werden. Erst danach wird 
der Wert negiert. Da würde er zwar in den int passen, aber es ist schon 
zu spät. Er ist bereits ein long.

Stefan schrieb:
> Aber hat das überhaupt was mit dem Thema 'implementation-defined

-32768 ist negativ :) Das hatte ich nur als besonders prägnantes 
Beispiel (-1 vs 1) gewählt. Das Problem besteht bei allen negativen 
Zahlen.

Das wiederum hat auch wenig mit dem Thread zu tun, denn die ganze 
Signed-Right-Shift-Problematik war auch nur ein Beispiel für 
implementation defined behaviour.

Stefan schrieb:
> Also macht der Compiler folgendes

Ja.

>     Was bewirkt das jetzt? Werden einfach die höherwertigen 16 Bit
> abgeschnitten? Dann hätte ich ja wieder das gewünschte Ergebnis.

Korrekt.

> Aber hat das überhaupt was mit dem Thema 'implementation-defined
> Sign-Extension' zu tun?

Nein.

> Angenommen die Zahl wäre -20000 statt -32768:
>   '((int16_t) -20000) >> 3)'
> Der Audruck '(int16_t) -20000' ergibt (ohne dass irgendwelche Überläufe
> aufteten) als Zweierkomplement
>   10110001 11100000

Hier ist kein Cast nötig, da 20000 in einen int16_t passt.

> Wenn ich das Zitat aus dem Standard und die Aussagen von Niklas richtig
> deute, tritt das Problem 'implementation-defined Sign-Extension' ja
> jetzt trotzdem auf (obwohl vorher kein Überlauf auftrat), nämlich
> einfach immer bei Bit-Shifting mit Signed-Integer, denn ja nach
> Implementierung kann die Verschiebung um 3 Bits nach rechts
> (erfahrungsgemäß) diese beiden Ergebnisse erzeugen:
>   11110110 00111100 (Sign-Extension, von links mit Einsen auffüllen)
>   00010110 00111100 (keine Sign-Extension, von links mit Nullen
> auffüllen)

Ja, richtig.