Shift + Multiplikation bei 32 Bit Controller

Gast #908620
Lesenswert?

Hallo,

für folgendes Problem habe ich keine Antwort gefunden:

Wenn im C-Code folgende Zuweisung stattfindet:

int x,a;
[...]
x = a * 100 >> 10;

Darf dann der Compiler "kürzen", sprich x = a * 25 >> 8 daraus machen? 
Ein Überlauf ist dann zwar immer noch möglich, das Ergebnis ist aber 
dennoch "genauer" als das nicht optimierte...
#908649
Lesenswert?

Wenn das Programm keine undefinierten Operationen enthält, dann darf der 
Compiler nur solche Optimierungen durchführen, die am Ergebnis nichts 
ändern.

Was dabei gern übersehen wird: Wenn jedoch undefinierte Operationen 
enthalten sind, dann darf etwas anderes herauskommen. Dazu zählt 
beispielsweise die Abhängigkeit von Nebeneffekten (i = i++).

Da die vorzeichenbehaftete Multiplikation bei Überlauf undefiniert ist, 
dürfte er in diesem Beispiel dann abkürzen, wenn ein Überlauf auftritt. 
Aber nur dann.
#908651
Lesenswert?

IMHO darf er das.

Meine Argumentation:
Bei der Multiplikation könnte ein Überlauf entstehen, da es sich
aber um int Arithmetik handelt, ist undefiniert was in so einem
Fall zu geschehen hat. Daher würde ein 'kürzen' des Ausdrucks
nichts an dieser Undefiniertheit ändern. Auch ein korrektes
Ergebnis ist schliesslich im 'undefinierten Fall' ein gültiges
Ergebnis.

Anders wäre es bei unsigned Arithmetik, bei der ja vorgeschrieben
ist, wie sich Überläufe verhalten müssen.
Gast #909028
Lesenswert?

Im Zweifelsfall würde ich im Ass-Listing nachsehen, oder besser, die 
Operationen auf mehrere Zeilen verteilen. Heutige Compiler sind schlau 
genug, damit umzugehen. Was soll sein?
Eine komplette Funktion in eine einzige Zeile zu packen, macht 
vielleicht viel Eindruck, ist aber nicht gut wartbar.
Gast #916645
Lesenswert?

Hallo nochmal,

vielen Dank für die Antworten.
Eins ist mir noch nicht ganz klar: Die Multiplikation hat doch höhere 
Präzedenz. Darf der Compiler dennoch machen was er will?

Ein ähnlicher Fall tritt nun zutage bei:

int x,a;
const unsigned char b = 8;
[...]
x = (a >> 8) * b;

Hier propagiert der Compiler die Konstante 'b' und berechnet b >> 8, was 
'0' ergibt. x ist also immer '0'! Ist das auch irgendwie mit "nicht 
definiert" zu argumentieren? Erhöhe ich den Typ von 'b' auf 16 bit 
(unsigned short) und mit Wert > 2^8, dann wird x auch mal > 0...
Gast #916665
Lesenswert?

Der Controller ist ein ARM7. Den vollständigen Testcode kann ich hier im 
Forum nicht bringen. Mir ist aufgefallen, dass in [...] ziemlich viel 
(geheimer!) Code stecken muss, der den Compiler zu dieser seltsamen 
Optimierung bringt. Die Zuweisung alleine in einer Funktion funktioniert 
wie gewünscht :-( Ebenso, wenn man 'b' nur als extern deklariert (aber 
das ist ja klar, weil dann keine Propagierung mehr möglich ist).
#916674
Lesenswert?

Ich kann in diesem Schnipsel nichts erkennen, was es dem Compiler 
erlaubt, daraus x=0 zu machen. Es sei denn es ergibt sich für den 
Compiler aus dem Kontext, dass stets (a >> 8) == 0 gilt.

Wenn du vermutest, dass es ein Fehler im Compiler ist: Du kannst 
natürlich darauf hoffen, dass er im Laufe der Jahre auch ohne dein Zutun 
von allein verschwindet. Aber schneller geht es, wenn du die Entwickler 
darauf stösst. Dies ist aber nur mit reproduzierbarem Testcode möglich.
Gast #916700
Lesenswert?

Ich schaue mal am Montag im Büro, ob ich den Fehler weiter einkreisen 
kann. Was das Ergebnis "=0" anbetrifft, hatte ich ja schon geschrieben:
"Erhöhe ich den Typ von 'b' auf 16 bit (unsigned short) und mit Wert > 
2^8, dann wird x auch mal > 0...".
Mit
const unsigned short b = 1024;

wird die Multiplikation durchgeführt laut asm-code (dann ist aber das 
Ergebnis möglicherweise nicht definiert wegen Überlauf).

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

oder

Mit Google-Account einloggen

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren