Eine (weitere) Integer-Promotion-Frage

[Bitflüsterer (Gast)]

Hallo,

(Mods: Ggf. bitte verschieben).

Ich habe mich hier im Forum schon mal an diesem Punkt blamiert, da 
sollte einmal mehr jetzt auch keine Rolle mehr spielen. :-)

In diesem Beitrag Beitrag "Re: womit füllt atmel bit shift (>>) die neuen bits auf?" 
wird im Zusammenhang mit einer Schiebeoperation von Johann L. (gjlayde) 
folgende Aussage gemacht.

> Es wird nur mit 8 Bits gerechnet, was allerdings der
>   C-Spezifikation entspricht, die ja eine Promotion auf
>   (unsigned) int vorschreibt. ...


Ist das nicht ein Widerspruch?

Ich meine, falls eine Promotion zu unsigned int stattgefunden hätte, 
dann müsste der Grund für die Berechnung mit 8Bit doch primär in der 
Optimierung zu sehen sein, oder?

Anders ausgedrückt, durch Promotion kann doch nur mindestens ein int 
oder unsigned int entstehen und kein 8Bit. Die 8 Bit entstehen dann doch 
durch die Optimierung.

Noch anders ausgedrückt, müsste der linke Operand (der Schiebeoperation) 
ein uint8_t ist, müsste doch erstmal eine Integer Promotion vorkommen, 
auch wenn die wieder wegoptimiert wird.

[Bitflüsterer (Gast)]

Sorry, verwurkselte Grammatik im letzten Satz:

Noch anders ausgedrückt, müsste, da der linke Operand (der 
Schiebeoperation)
ein uint8_t ist, doch erstmal eine Integer Promotion vorkommen,
auch wenn die wieder wegoptimiert wird.

[Johann L. (gjlayde)]

Ja. In dem Beispiel kommt aber immer das gleiche raus, d.h. die Rechnung 
in 8 Bits auszuführen ist an der Stelle legal. Das wollte ich damit 
ausdrücken.

Manchmal auch als "as if" Regel bezeichnet. D.h. der Code verhält sich 
genau so, "als ob" zuerst aus 16 Bits expandiert wird, die Rechnung 
damit ausgeführt und dann zurückgestutzt auf 8 Bits wird.

Das "genau so" bezieht sich dabei auf die C-Sicht, die ja blind ist für 
Dinge wie z.B. Codegröße oder Ausführungszeit.

[Bitflüsterer (Gast)]

@ Johann L.

Aha. Dankeschön.