"xor eax,eax" leert eax?

[Murray]

Hallo, ich habe heute gelesen, dass folgende Anweisung eax leert.

xor eax,eax

Das verstehe ich nicht. xor bedeutet doch: Entweder a oder b aber nicht beide und nicht keins (in etwa). Wenn ich das jetzt auf die Bits anwende:

11001001
  XOR     = 11101111
00100110

Das ist doch nicht geleert. Habe ich da jetzt was falsch verstanden?

Schonmal Danke für eure Hilfe!

Murray

[Murray]

Sorry für das Posting. Könnt es gerne löschen, ich war wieder mal selten doof.
10101010 XOR 10101010 = 0000000 Ist doch logisch (im wahrsten Sinne des Wortes)
Nochmal sorry. Ihr wisst schon: Die Hitze! *verkriech*

[malfunction]

Du kannst ja auch Alternativen zu XOR EAX,EAX nehmen. Da wäre z.B.
sub eax,eax <-- das VC++ mag das scheinbar auch recht gern
mov eax,0
and eax,0

[DocJunioR]

XOR eax, eax

Ist eine Optimierung, die hoch gelobt wird, da diese Anweisung nur einen Takt benötigt. Auf dem 486 waren es für den Move-Befehl afaik noch ganze 2 Takte.
Allerdings sind die Pentiumrechner so konstruiert, dass der Befehl mov auch nur noch einen Takt braucht. insofern ist imho xor eax, eax nichts weiter als Verwirrend für Leute, die Assembler erst anfangen oder nur selten benutzen..

cYa
DjR

[Harrison Bergeron]

@DocJunioR

Ein weiterer Vorteil der XOR-Variante ist, dass kleinerer Code erzeugt wird. Das ist zwar meistens völlig unerheblich aber bei 4k-Intros z.B. zählt jedes Byte.

B800000000    MOV EAX, 0

5 Bytes

33C0          XOR EAX, EAX

2 Bytes

H.B.

[japro]

eränzung:
mov bringt dann speedtechnische vorteile wenn mehrere hintereinander sind -> paralellisierung:

mov eax, 0
mov ebx, 0

dürfte schneller sein als

xor eax, eax
xor ebx, ebx

aber wie immer weiss mans nur wenn mans nachmisst genau.

[Bashar]

auch schneller als

xor eax, eax
mov ebx, eax

?

[Christoph]

Bashar schrieb:

auch schneller als

xor eax, eax
mov ebx, eax

?

Vermutlich.
"mov ebx, eax" benötigt den Wert von eax. Dieser steht aber erst nach "xor eax, eax" fest.
Also können diese Befehle nicht parallel ausgeführt werden.

[fit]

Vermutlich.
"mov ebx, eax" benötigt den Wert von eax. Dieser steht aber erst nach "xor eax, eax" fest.
Also können diese Befehle nicht parallel ausgeführt werden.

Und ich dachte immer, die CPU arbeitet nur linear...*irr*
...kannst Du bitte mal ein paar Beispiele geben, was die CPU noch so parallel machen kann ?

[Nobuo T]

Hi.

Das kommt AFAIK auch auf die CPU an.
Den AMDs bleibt zB. die loop-Instruction quer in den Pipes stecken
(weitere Infos dazu gibts in den Docs zu den entsprechenden CPUs)
Aber grundsaetzlich koennen Instructionen parallel verarbeitet werden, die nicht mit Werten in Registern/Speicher arbeiten, die erst von der vorherigen Instruction veraendert wurden. (klingt logisch, oder?)
In einem solchen Fall muss schliesslich erst einmal gewartet werden, bis das Ergebnis der vorherigen Instruction vorliegt.
Auch toedlich fuer eine parallele Verarbeitug von Instrucitonen sind haeufige verzweigungen. (bedingte Spruenge)
Hier wird zwar IMHO noch durch branche prediction versucht, zu erraten, ob nun der code an der Zieladdresse des Jumps ausgefuehrt werden soll oder nicht, aber manchmal vertut sich der Rechenknecht da leider.

[fit]

aso..thx.

aber es gibt doch sicher eine grenze/maximum für die anzahl der parallel zu verarbeitenden operationen, oder ?
wo liegt diese ungefähr z.b. bei amd oder intel cpu ?