4. mov vs. xor

mov vs. xor

  • 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
  • T

    Original erstellt von Kal El:
    **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?
    **

    Wenn der Code nur einmal aufgerufen wird ja. Wenn der Betreffende Algorithmus aber eine Schleife enthält, die 10 Milliarden mal aufgerufen wird und der Inhalt der Schleife nur 20 Takte lang ist, nein.

    0
  • R

    Original erstellt von Kal El:
    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?

    Natürlich sind 2 Takte irgend wo rauszuholen nicht welt bewegend und es ist auch nicht vernünftig, dafür irgend wo inline Assembler oä. einzusetzen. Aber davon auszugehen, dass man eine 2GHZ CPU hat oder man 1GB RAM für ein Appel und ein Ei bekommt, ist volkommen falsch! Heute benutzen Leute Geräte, die von der Leistung so hochgepusht wurden (oft an falscher Stelle, anstelle die dumme x86 Architektur zu ersetzen, hat man einfach die MHZ Schraube hochgedreht, sieht auch viel toller aus... Ich kann in einen Trabbi auch einen Porsche Motor einbauen, ist aber auch nicht das ware), als bessere Schreibmaschine und warum das alles? Weil sich Firmen denken, ach Computer sind so billig geworden. Es gibt ein sehr verbreites OS, was alle 3 Jahre in einer neuen Version rauskommt, idr. mit minimalen Änderungen, aber trotzdem deutlich höhere Hardware Anforderungen hat. Den Leuten werden Textprogramme forgesetzt, von denen sie vielleicht 5% nutzen und mit dem Rest total überfordert sind.

    Die NASA hat es mir 32KB RAM in den Apollo Kapseln geschafft Leute sicher zum Mond zu bringen! Wenn ich heute einen kleinen Satz tippen will, soll ich mir gleich 256MB RAM kaufen!

    Ein Marsroboter hatte eine 80C85 CPU mit 176KB PROM und 576KB RAM und konnte damit nicht nur sich selbst steuern, sondern konnte auch Hochauflösende Aufnahmen und Wissenschaftliche Daten senden.

    Was wurde falsch gemacht?

    0
Anmelden zum Antworten