Hallo,
oftmals benötigt man Vergleiche mit 0 in C-Programmen. Mir fallen
spontan 4 Möglichkeiten ein, solch einen Vergleich zu schreiben:
1
if(foo==0){...
2
3
if!(foo>0){...
4
5
if(foo!=1){...
6
7
if(foo<1){...
Was ist denn im Sinne von effizientem (d.h. kürzestem) AVR-Code die
beste Lösung? Oder spielt das alles keine Rolle - Ist der Optimierer so
"schlau" und macht aus den obigen Beispielen immer den selben
(optimalen?) Code ?
Gruß
Andreas
-> Da musst du mir mal erklären, was das mit einem Vergleich mit 0 zu
tun hat.
Deine restlichen Alternativen hängen vom Variablentyp ab, da kann man
nichts zu sagen.
> -> Da musst du mir mal erklären, was das mit einem Vergleich mit 0 zu> tun hat.
Anscheinend geht es ihm nur um 0 oder 1, also binär. Ansonsten würde es
nicht viel Sinn ergeben.
Hallo,
Grundsätzlich sollte man dem Compiler die Sache so klar wie möglich
beibringen. D.h. ich erwarte eignetlich, dass er (i == 0) und (!i) in
den gleichen Assembler umsetzt.
Wenn man (!(i>0)) schreibt nötig man den Compiler u.U. wirklich einen
compare einzubauen, muss aber nicht sein.
Um sicher zu sein, hilft nur der Blick ins Assemblerlisting.
Gruß
Patrick
Patrick Markl schrieb:
> Wenn man (!(i>0)) schreibt nötig man den Compiler u.U. wirklich einen
Ganz abgesehen davon, dass !(i>0) je nach Datentyp nicht dasselbe ist
wie i==0
Patrick Markl schrieb:
> D.h. ich erwarte eignetlich, dass er (i == 0) und (!i) in> den gleichen Assembler umsetzt.
Yep. Daher sollte man die Form !i auch der Lesbarkeit halber nur
dann verwenden, wenn i tatsächlich einen Boolean repräsentiert
(egal, ob nun vom Typ `int' oder C99-mäßig vom Typ `bool').
N'abend,
es ist ja so: Abh. vom Problem bzw. Algorithmus macht es durchaus Sinn
aus Gründen der Lesbarkeit des Codes ein "kompliziertes" Konstrukt z.B.
1
if(!(foo>0)){...
zu schreiben.
Mir ist auch klar, dass meine o.g. Beispiele von Datentyp (bin mal von
uint8_t ausgegangen) abhängen.
> if(foo != 1) { ...> -> Da musst du mir mal erklären, was das mit einem Vergleich mit 0 zu> tun hat.
Ich dachte hier z.B. an eine Variable (uint8_t) die 0 wird wenn
irgendwas passiert. Im Normalfall ist die eben 1 ...
> Um sicher zu sein, hilft nur der Blick ins Assemblerlisting.
Habe ich bisher nie gemacht... Ich seh mir das mal an ...
Alles klar soweit - danker erstmal!
Gruß und schönen Abend
Andreas
Wenn man das Letzte rauskitzeln will, dann kann es nebem dem Unterschied
in der Bedeutung durchaus einen Unterschied machen, ob man
if (x != 0)
oder
if (x == 1)
schreibt. Denn es kann sein, dass aus der vorherigen Operation heraus
der Zustand "ist Null" noch im Statusregister steht. Ein Compiler ist
manchmal in der Lage, dies entsprechend auszunutzen und kann dann in der
ersten Variante den Vergleich einsparen. In der zweiten Variante nur,
wenn er genau weiss, dass nur die Werte 0 und 1 überhaupt möglich ist
(GCC kann sowas tatsächlich rauskriegen, bei anderen
Mikrocontroller-Compilern würde ich darauf nicht wetten).
Je nach Architektur kann ein Vergleich mit 0 ausserdem billiger sein,
als einer mit einem anderen Wert. Dies trifft auch auf AVR zu, nicht
zuletzt dann wenn der Wert in einem der ersten 16 Register liegt.
Ob du allerdings
if (x > 0)
oder
if (!(x <= 0))
schreibst, ist üblicherweise egal. Die Negation des zweiten Ausdrucks
wird ein nicht völlig primitiver Compiler in die Sprungbedingung
einbauen. Wobei er das bei vorzeichenlosem Datentyp oder als
vorzeichenlos bekanntem Wertebereich u.U. in ==0 umwandelt, weil nicht
selten billiger.
Uboot- Stocki schrieb:
>> if(foo != 1) { ...>> -> Da musst du mir mal erklären, was das mit einem Vergleich mit 0 zu>> tun hat.>> Ich dachte hier z.B. an eine Variable (uint8_t) die 0 wird wenn> irgendwas passiert. Im Normalfall ist die eben 1 ...
Das ist unklug.
Versuch bei solchen Dingen immer alles in das Schema zu packen:
Es gibt nur 0 oder nicht 0. (1 ist nicht 0, aber 5 ist auch nicht 0).
Wobei 0 für "nichts ist passiert" steht.
Selbst wenn es zur Zeit in einer Variablen nur 0 oder 1 geben kann,
geschieht es in der Praxis immer wieder, dass es plötzlich auch noch 2
geben kann (zb als zusätzlichen Fehlercode). Wohl demjenigen, der
vorausschauend gearbeitet hat und das berücksichtigt hat.
Dann gibt es plötzliche einen riesen Unterschied zwischen
1
....
2
if(x==0){
3
// kein Fehler passiert
4
}
und
1
...
2
if(x!=1){
3
// kein Fehler passiert
4
}
Das Erste funktioniert weiter wie gehabt, das Zweite erfordert
Anpassarbeit.
Eine eigene Frage?
Dieser Thread ist über 17 Jahre alt.
Stell sie in einem eigenen Thread – dort lesen mehr Leute mit, und sie wird öfter und schneller beantwortet.
