4. mov vs. xor

mov vs. xor

  • P

    Also ich habe schon oft gelesen, das zB

    xor ax, ax

    schneller sei, als

    mov ax, 0

    Jetzt habe ich in einer Clock-Tabelle nachgesehen:

    [  Architektur  ]
[mne]  [operands]      808x   286   386   486
MOV    reg,immed         4     2     2     1
XOR    reg,reg           3     2     2     1

    Heißt das, dass diese Behauptung nur für ältere CPUs gilt, oder habe ich da etwas falsch verstanden?

    lg, phreaking

    0
  • C

    So ist es, macht heute keinen Unterschied mehr. (außer, daß xor ax,ax cooler aussieht 😉 )

    0
  • V

    Original erstellt von Cocaine:
    So ist es, macht heute keinen Unterschied mehr. (außer, daß xor ax,ax cooler aussieht 😉 )

    Wie stehts mit der Größe des Codes? Ich schätze, da gewinnt dann immer der kleinere Code, wenn sie sonst gleich schnell sind.

    0
  • N

    mov ax,0000h => B8 00 00
    xor ax,ax => 33 C0
    😉

    0
  • P

    Aha, danke euch allen!

    greetz, phreaking

    0
  • C

    Auch wahr - aber genauso gut könnte man argumentieren, daß man - falls dem mov ax,0 ein weiterer mov mit anderem Register folgt - besser diese Version verwendet, da dann beide movs in einem Takt ausgeführt werden...

    0
  • V

    Original erstellt von Cocaine:
    Auch wahr - aber genauso gut könnte man argumentieren, daß man - falls dem mov ax,0 ein weiterer mov mit anderem Register folgt - besser diese Version verwendet, da dann beide movs in einem Takt ausgeführt werden...

    Ja. Und die Pipelines gleichmäßig auslasten, Befehler verschränken und alle das, was ein guter C++-Compiler inzwischen von alleine macht. Ist ja nur Erbsenzählerei, aber davon sauviel.

    0
  • H

    wenn ein befehl kleiner ist [und xor ax,ax ist kleiner als mov ax,0]
    dann werden auch weniger takte verbraucht um den befehl ausm speicher zu holen.
    naja, da muss man auf viele sachen achten.
    und wie Michael Abrash schon sagte: nur zeitmessen sagt euch, welcher code
    schneller ist.

    0
  • -

    Aber auch messen taugt nicht immer, denn das kann von Maschine zu Maschine variieren. Fün nen AMD Athlon wird anders optimiert als für nen Pentium III.

    mfg
    -bg-

    0
  • T

    Original erstellt von Loggy:
    **wenn ein befehl kleiner ist [und xor ax,ax ist kleiner als mov ax,0]
    dann werden auch weniger takte verbraucht um den befehl ausm speicher zu holen.
    **

    <kleinkrammode>
    Der Prozi holt aber immer 4 Bytes auf einmal, gilt also nur, wenn man damit eine DWORD-Grenze überschreitet 😃
    </kleinkrammode>

    [ Dieser Beitrag wurde am 11.11.2002 um 14:33 Uhr von TriPhoenix editiert. ]

    0
  • ?

    KLUGSCHEISSER !! 😃

    0
  • ?

    wenn 2 mal xor gemacht wird bzw. mov, würde man mehr speicher bei mov (bzw mehr 4bytes) gehollen. könnte langsammer sein.

    rapso->greets();

    0
  • G

    mov hat einen entscheidenden Vorteil gegenüber xor, da dort alle Flags ihren Wert behalten.

    aus einer schon etwas älteren Intel Doku:

    MOV - Move Byte or Word

    Usage: MOV dest,src
    Modifies flags: None

    Copies byte or word from the source operand to the destination
    operand. If the destination is SS interrupts are disabled except
    on early buggy 808x CPUs. Some CPUs disable interrupts if the
    destination is any of the segment registers

    Clocks Size
    Operands 808x 286 386 486 Bytes

    reg,reg 2 2 2 1 2
    mem,reg 9+EA 3 2 1 2-4 (W88=13+EA)
    reg,mem 8+EA 5 4 1 2-4 (W88=12+EA)
    mem,immed 10+EA 3 2 1 3-6 (W88=14+EA)
    reg,immed 4 2 2 1 2-3
    mem,accum 10 3 2 1 3 (W88=14)
    accum,mem 10 5 4 1 3 (W88=14)
    segreg,reg16 2 2 2 3 2
    segreg,mem16 8+EA 5 5 9 2-4 (W88=12+EA)
    reg16,segreg 2 2 2 3 2
    mem16,segreg 9+EA 3 2 3 2-4 (W88=13+EA)
    reg32,CR0/CR2/CR3 - - 6 4
    CR0,reg32 - - 10 16
    CR2,reg32 - - 4 4 3
    CR3,reg32 - - 5 4 3
    reg32,DR0/DR1/DR2/DR3 - 22 10 3
    reg32,DR6/DR7 - - 22 10 3
    DR0/DR1/DR2/DR3,reg32 - 22 11 3
    DR6/DR7,reg32 - - 16 11 3
    reg32,TR6/TR7 - - 12 4 3
    TR6/TR7,reg32 - - 12 4 3
    reg32,TR3 3
    TR3,reg32 6

    XOR - Exclusive OR

    Usage: XOR dest,src
    Modifies flags: CF OF PF SF ZF (AF undefined)

    Performs a bitwise exclusive OR of the operands and returns
    the result in the destination.

    Clocks Size
    Operands 808x 286 386 486 Bytes

    reg,reg 3 2 2 1 2
    mem,reg 16+EA 7 6 3 2-4 (W88=24+EA)
    reg,mem 9+EA 7 7 2 2-4 (W88=13+EA)
    reg,immed 4 3 2 1 3-4
    mem,immed 17+EA 7 7 3 3-6 (W88=25+EA)
    accum,immed 4 3 2 1 2-3

    Trotzdem sollte man xor imho verwenden, sofern Flags keine Rolle spielen.

    0
  • J

    ich würd zu mov neigen (ausser man ist voll auf kleine programme angewiesen) weil wie gesagt der unterschied nimmer so gross bzw. weil mehrere movs hintereinander sogar schneller sind... und dann kommt noch das argument das das mov irgendwas,0 in meinen augen besser zeigt was gemacht wird

    0
  • B

    letzteres ist kein Argument, wenn du Code willst, der besser das widerspiegelt was du machen willst, mußt du eine Hochsprache nehmen.

    0
  • J

    genau aus dem grund schreibe ich extra unübersichlichen c code weil für lesbaren code ja c++ vorhanden ist.

    0
  • B

    willst du mir damit sagen, dass du Assembler für eine problemorientierte Sprache hältst?

    0
  • J

    es ging mir darum das, wenn man kein klares urteil fällen kann was von beidem schneller is. das man auf andere kriterien zurückgreiffen muss und dann finde ich das sinnvoll...

    0
  • K

    Moin, Moin...

    Mag sein, dass ich etwas nicht so ganz richtig verstanden habe bezüglich Optimierung, aber macht es heutzutage wirklich einen Unterschied, ob ich ein Register mit mov oder mit xor lösche? In früheren Zeiten mag das ein Frage gewesen sein, über die sich nachzudenken lohnte. Heute dürfte der Unterschied wohl kaum ins Gewicht fallen. Auch der Speicherplatzbedarf ist doch wohl kein Argument für oder gegen eine der beiden Möglichkeiten. Wenn mein Programm 100 KB Speicher nutzt, ist ein gespartes Byte doch irgendwie irrelevant. Und ob ich meiner Hyper-Mega-CPU mit 2 GHz zwei Taktzyklen erspare, ist wohl auch eher unwichtig. Gibt es nicht wichtigere und lohnendere Optimierungsansätze?

    Ciao...

    0
  • ?

    hey Kal El:

    Prozessoren stecken nicht nur in deinem PC...

    0
Anmelden zum Antworten