Hallo Martin,
wie ich schon Peter gegenüber angedeutet habe, geht es in den meisten Fällen, wo einzelne Bits abgefragt werden, nicht um die tatsächliche Wertigkeit des jeweiligen Bits; daher ist hier der Vergleich !=0 eigentlich sinnfrei (schadet aber auch nicht). Das Funktionsergebnis wird ja im realen Kontext sowieso auf "ungleich Null" abgefragt.
Ja, nur legte er Wert darauf, dass er den Bit-Wert bräuchte. Deswegen habe ich das genau so gemacht.
Vergessen:
long int time1 = clock() / (CLOCKS_PER_SEC / 1000.0);
Oh ja, ein Fehler beim kopieren in die Antwort.
Und dann noch in einer so merkwürdigen Notation. :-|
Einfach die Ausgabe von objdump unter Linux, was besseres habe ich nicht zur Hand.
Hier erkennt man aber, dass der Compiler den Ausdruck umformuliert hat. Was hier in Assembler wirklich formuliert wird, ist "return ((i>>j) & 1)". Ich finde das bemerkenswert.
Ja, das ist mir auch aufgefallen.
Keineswegs. Die test-Anweisung ist nämlich ein AND, bei dem das Ergebnis nicht gespeichert wird, gerade für solche Bit-Tests gedacht.
Ah ok, damit wird das klarer.
Auf einem Sun-Kiste habe ich das auch noch spaßeshalber laufen lassen. (Ultrasparc 3 oder sowas). Da ist shift doppelt so schnell. Zeigt also schön, dass man schon genau wissen muss, für welchen Prozessor man programmiert, wenn man mit sowas anfängt. Könnte natürlich auch sein, dass der gcc für Sparc einfach schlechter optimiert. Das hilft einem aber auch nichts, wenn man nicht wirklich Assembler programmiert.
Grüße
Daniel