OSDev.org

• This is not completely the case. Some operations are slower on the 8-bit and particularly 16-bit registers.
• For purposes of alias consideration, xL = xH = ExX = RxX
• If you do

  Code: Select all

      movl (some_address), %eax
      add $1, %ax
  

  then the add will be stalled while waiting for the completion of the load
• A few operations, such as DIV, are quicker on the smaller registers (Time taken ∝ register size in bits)
• Operand size prefixes add an extra byte to an instruction, thus wasting some instruction fetch bandwidth

• Use 32-bit registers always for n ≤ 32 bit operations. Use 64-bits for 33 ≤ n ≤ 64 bit operations
• If doing a division, consider if doing a smaller divide and mov[zs]x would be a good idea
• Always load the full target register. Note that for 64-bit mode, loading the Exx registers will always load the upper 32-bits of Rxx with zero.
• Generally avoid the xH registers.They alias with their corresponding xL register, are in a less useful position, and cannot be used in any REX-prefixed instruction. Remember however that you get DIL/SIL/SPL*/BPL*/RnL in 64-bit mode
• In C, on x86, you may get performance benefits by casting to (int16_t) before doing a division. Don't count on the compiler to understand that however. Expect doing this to hurt other architectures, as they don't get free result truncation.

For optimizing, repeat after me: I will not use 16-bit LEA. I will not use 16-bit LEA†. Got that?

Performance information here is taken from AMD's optimization guide & Agner Fog's x86 optimization reference.

* I don't see much use to these two. Well; I accept BPL, you may be eliding your frame pointer. SPL, on the other hand, seems rather utterly useless
† Or anything involving 16-bit addressing

bewing wrote:There are a few other small issues that can complicate what Owen said -- in a real world that is more complicated than your code examples. The upper 16bits of the Exx registers can be used to store variables. These variables can be accessed much more quickly than going to memory. Using the Exx registers preferentially will trash the upper parts of the registers for only a tiny performance boost, whereas using them for variable storage will give you a much better performance boost. And the same goes for the xH registers -- not using them gives you a small boost, using them carefully to store variables gives you much more.

But doing this makes your code more complex, and harder to read and maintain.

    mov %eax, %ebx
    shr $16, %ebx
    ...
    code working on ebx
    ...
    shl $16, %ebx
    and $0000ffff, %eax
    or %ebx, %eax

Teehee wrote:Thanks all, very usefull informations.

---

This code has 4 bytes:

Code: Select all

use32
        inc eax
        inc ecx
        inc ebx
        inc edx    

in a 32 bit system it means the CPU will execute these 4 instructions in a single step(clock?)?

turdus wrote:The idea behind that is locality, most applications are happy with 4G memory and variable ranges -2billion to 2billion.

Tosi wrote:Outside of some modern games, what application needs over 4 GB of RAM?

Tosi wrote:Definitely not an operating system, unless it is for a specific domain.
A typical operating system should use as little memory as possible, and in general be as invisible to the user applications as possible except in system calls.

Teehee wrote:

turdus wrote:The idea behind that is locality, most applications are happy with 4G memory and variable ranges -2billion to 2billion.

Sorry, i didn't understand this part.

Owen wrote:

Teehee wrote:Thanks all, very usefull informations.

---

This code has 4 bytes:

Code: Select all

use32
        inc eax
        inc ecx
        inc ebx
        inc edx    

in a 32 bit system it means the CPU will execute these 4 instructions in a single step(clock?)?

No. Depends a lot upon the processor. An Athlon 64 will (best case) execute that in 2 clocks, same for a Core 2. An i7 will possibly do that in 1. A 386 will probably take somewhere in the region of 8-12. A Pentium will probably take 4.

Theres no hard and fast rule. See your processor's optimization guide.