2 int8 in ein int16 reinkopieren?

Matthias Lipinsky schrieb:
>>uint16_t var3 = (var1 << 8) | var2;
>
> Ich vermute mal, das hier nur der Wert von var2 in var3 stehen wird.

Nein. (Integer-Promotion!)

Floh schrieb:
> Was erwartest du denn für ein Verhalten, wenn du zwei
> VORZEICHENBEHAFTETE 8-Bit Werte in einen 16bit Wert verwandelst?

Und wo bitte siehst du in diesem Thread "VORZEICHENBEHAFTETE 8-Bit 
Werte"?

Floh schrieb:
> Ich beziehe mich auf den Threadtitel :-)
> "2 int8 in ein int16"

Ups.
Ach na ja, wer achtet denn schon auf den Titel. ;-)

Bei der Union ist das Ergebnis nicht portabel, ist also mithin von 
verwendeter Plattform und Compiler abhängig (ein avr-gcc ist was anderes 
als ein arm-gcc).

Auch denn in einem speziellen Fall eine Union ein paar Instruktionen 
sparen sollte, ist die portable und lesbare Variante vorzuziehen.

Den Code mit Casts zu Union und/oder Type-Punning zu verunstalten um ein 
paar Assembler-Instruktionen rauszuhacken ist nicht wirklich eine gute 
Idee.

In der portablen C99 Variante

1

#include <stdint.h>

2

3

uint16_t glue (uint8_t lo, uint8_t hi)

4

{

5

    return (hi << 8) | lo;

6

}

Gibe es 5 Operationen: Ein Shift, ein Or, zwei 8->16 Promotions und eine 
16-Bit Zuweisung.

GCC verliert hier leider gerne den Überblick über das Gesamtbild, das 
sich dem Assembler-affinen Programmierer als 2 8-Bit Zuweisungen 
darstellt, die bei geschickter Umsetzung des umgebenden Codes sogar 
entfallen können.

Diese Diskrepanz ist es, welche "erfahrene" Entwickler zu Union-Hacks 
greifen lässt. Aber führt man das Szenario konsequent fort, frogrammiert 
man Assembler in C und hackt sich hinter jeder verlorenen Instruktion 
her...

Dann sieht der Code irgendwann aus wie Sauerkraut, obwohl die Ursache 
zwo Assembler-Instruktionen von einer Compiler-Version waren, die schon 
seit Jahren nicht mehr eingesetzt wird. Und keiner rafft's mehr. Weder 
was wirklich im Code passiert, nach warum es genau so passiert.

Und Ja, das Problem ist im GCC bekannt: PR41076. Und ja, auch 
GCC-Entwickler wissen wie guter Code auszusehen hat und sind nicht 
komplett doof ;-)

Ja, bei so kurzen Funktionen ist das durchaus sinnvoll.

Wobei "inline" ja auch nur eine Empfehlung ist und vom Compiler nicht 
zwangsläufig befolgt wird. Umgekehrt kann der Compiler auch automatisch 
eine Funktion inline expandieren, wenn es dem Optimizer sinnvoll 
erscheint. Bei einer derart kurzen und einfachen Funktion kann man 
eigentlich drauf wetten.

LittleBigEndian schrieb:
> Johann L. schrieb:
>> Bei der Union ist das Ergebnis nicht portabel, ist also mithin von
>> verwendeter Plattform und Compiler abhängig (ein avr-gcc ist was anderes
>> als ein arm-gcc).
>
> Das stimmt so nicht.

Doch, das stimmt. Und wenn man es streng nach ISO C sieht, geht es sogar 
noch einen Schritt weiter: Da ist nicht einmal definiert, was überhaupt 
passiert, wenn du solche Schweinereien versuchst.