4. LEA Befehl

LEA Befehl

  • N

    rapso schrieb:

    z.b. [eax*4+ebx]; ansonsten waeren das 2befehle mit einem datahazard.

    😕 Aber das doch eigentlich wirklich nur theoretisch - praktisch wird dir da wohl kaum was zwischen deinen 2 Befehlen die Register durcheinanderwirbeln.

    0
  • ?

    ich versteh folgendes nicht:
    daten vom stack sind einfach zu adressieren, also z.B.

    mov eax, [ebx+4]

    wo kommt da eine adresse ins spiel die schwer zu berechnen ist???

    0
  • C
    Mod

    ich denke, man sollte hier sinnvollerweise mit 16bit argumentieren - im 32bit-modus könnte man auf lea in der regel verzichten. Im 16bit Modus sind die möglichen Adressierungsarten ja viel eingeschränkter, es gibt ja im Grunde nur [0/BX/BP+0/SI/DI+disp] oder [AX/BX/CD/DX/SI/DI/BP/SP] - dabei gehen einem leicht die Register aus, wenn man mehrere solche Berechnungen vorzunehmen hat. lea erlaubt es, derartige häufige Berechnungen ohne zusätzlich Register und ohne Veränderung der Flags vorzunehmen. Das ist eleganter als manuelles Addieren und verkleinert den Code insgesamt.

    0
  • N

    Huch, ich haette das eher andersherum gesehen - erst mit 32Bit wird LEA doch richtig praktisch wegen der zusaetzlichen Adressierungsmoeglichkeiten.
    Bietet einem eine elegante Moeglichkeit, mehrere Additionen und Shifts in einem Befehl auszufuehren.

    0
  • C
    Mod

    Nobuo T schrieb:

    Huch, ich haette das eher andersherum gesehen - erst mit 32Bit wird LEA doch richtig praktisch wegen der zusaetzlichen Adressierungsmoeglichkeiten.
    Bietet einem eine elegante Moeglichkeit, mehrere Additionen und Shifts in einem Befehl auszufuehren.

    praktisch ja, aber die frage war - so wie ich es verstehe - eher die, warum es den befehl überhaupt gibt - und im 32bit Modus existiert er sicherlich primär deshalb, weil er von 16bit geerbt wurde.

    0
  • R

    Nobuo T schrieb:

    rapso schrieb:

    z.b. [eax*4+ebx]; ansonsten waeren das 2befehle mit einem datahazard.

    😕 Aber das doch eigentlich wirklich nur theoretisch - praktisch wird dir da wohl kaum was zwischen deinen 2 Befehlen die Register durcheinanderwirbeln.

    aus
    kea eax, [eax*4+ebx]

    wird, wenn ich mich recht entsinne

    mul eax,4
    add eax, ebx

    dabei greiffst du auf eax zu nachdem du es gerade modifiziert hast, RAW datahazard. (ja man kann auch shiften, aber es wird RAW nicht verhindern.

    ueberseh ich was 😕

    0
  • N

    Achso jup. Solche Hazards treten zwar auf, wirken sich beim x86 tatsaechlich aber nicht weiter aus. Wenn das Ergebnis der Multiplikation fuer die Addition tatsaechlich noch nicht vorliegen sollte, wird entsprechend lange blockiert.

    0
  • R

    Nobuo T schrieb:

    Achso jup. Solche Hazards treten zwar auf, wirken sich beim x86 tatsaechlich aber nicht weiter aus.

    widerspruch zu

    Wenn das Ergebnis der Multiplikation fuer die Addition tatsaechlich noch nicht vorliegen sollte, wird entsprechend lange blockiert.

    genau das ist das problem beim hazard und genau das kann mit LEA leicht wetgemacht werden, zudem ist ein multiply-add der nuetzlichste befehl den man haben kann 🙂

    0
  • N

    Oh, ja, los - lass uns Haare spalten. 😃

    rapso schrieb:

    Nobuo T schrieb:

    Achso jup. Solche Hazards treten zwar auf, wirken sich beim x86 tatsaechlich aber nicht weiter aus.

    widerspruch zu

    Wenn das Ergebnis der Multiplikation fuer die Addition tatsaechlich noch nicht vorliegen sollte, wird entsprechend lange blockiert.

    Definition eines RAW Hazard ist laut Wikipedia

    Wikipedia schrieb:

    A RAW Data Hazard refers to a situation where we refer to a result that has not yet been calculated, for example:

    i1. R2 <- R1 + R3
    i2. R4 <- R2 + R3

    The 1st instruction is calculating a value to be saved in register 2, and the second is going to use this value to compute a result for register 4. However, in a pipeline, when we fetch the operands for the 2nd operation, the results from the 1st will not yet have been saved, and hence we have a data dependency.

    We say that there is a data dependency with instruction 2, as it is dependent on the completion of instruction 1

    So weit, so gut.
    Ich definiere "weiter auswirken" zudem als merkliche Beeintraechtigung - zB. wesentliche Verlangsamung oder sogar ein falsches Datum im Quellregister bei der Addition. Ersteres wird bei auch nur halbwegs brauchbarem Code nicht auftreten und zweites beim x86 so wie so nicht. -> Ich sehe da keinen Widerspruch.

    rapso schrieb:

    genau das ist das problem beim hazard und genau das kann mit LEA leicht wetgemacht werden, zudem ist ein multiply-add der nuetzlichste befehl den man haben kann 🙂

    Alle moeglichen Hazards auszubuegeln ist eine hohe Kunst. Sonst stimme ich dir natuerlich zu.

    0
  • R

    Nobuo T schrieb:

    Ich definiere "weiter auswirken" zudem als merkliche Beeintraechtigung - zB. wesentliche Verlangsamung oder sogar ein falsches Datum im Quellregister bei der Addition.

    so ganz versteh ich nicht was du dann sagen wolltest mit "weitere auswirkungen", nur dass du ohne LEA auskommen koenntest?

    Ersteres wird bei auch nur halbwegs brauchbarem Code nicht auftreten und zweites beim x86 so wie so nicht.

    data hazards waren vor der OutOfOrder ausfuehrung mit das schlimmste fuer die performance, da es jede pipe zum stehen bringt. LEA war da schon eine gute gegenmassnahme, viele haben das auch nur als optimierung beim rechnen genutzt.

    0
Anmelden zum Antworten