Agner`s CPU blog

I kinda wonder how the OS would handle the following case:
- Load program 1 to offset 0010 0000h
- Load program 2 to offset 0020 0000h
- Load program 3 to offset 0030 0000h
- The user unexpectedly loads a 300mb file in program 2, which causes a surprise 300mb allocation on the heap. Where does the OS place this allocation?

--------

One suggestion: remove "Indexing into the register file".

Rationale:

The implementation of register file indexing on an out-of-order CPU looks like this:

- Option #1: Stall hard at the register rename stage until the indexing value becomes valid and can be read. Then read the value through a special feedback path from the register file/bypass network/data cache up to the renamer. If the index is loaded from memory, this will stall for at least 3 or 4 cycles even in the best case. Resume execution.

- Option #2: Speculatively assume that the indexed register will not be the same as any other subsequent operation. Record the previous value of every single rename in a special queue or register file after this until the indexing value can be read (through the special feedback path), or alternatively backup the whole renaming register file. When the indexing resolves, check that no reads/writes have been done to the resolved register. If there are any reads, trigger a branch prediction fail and restore the CPU state to the last known valid state.

- Option #3: Have a specialized predictor that remembers which indexed register reads/writes cause branch prediction fails. Use option #2 by default, except for indexed-register-reads/writes that trigger fails which use option #1.

Even on in-order CPUs, this is a problem because this defeats the bypass network for register reads - you can't bypass a register that you can't figure out what it's going to be yet! Having to stall multiple cycles to avoid potential hazards make register-file indexing very costly, which defeats the purpose.

--------

2nd suggestion: Make operand size for tiny format 32bits, not 64bits (except mov). Consider trading tiny setbit/clearbit/xor/reversesubtract/andnot for arithmetic shift right and 64bit add/sub. Consider adding the option for 32bit signed indexes in address calculations or sign extending instead of zero extending 32bit operations to 64bit by default.

Rationale:

32bit integer operations are extremely extremely common in C/C++ code, due to how the LLP64 (win64) and LP64 (OSX+Linux) models work. Almost only pointers will be 64bits in a typical program (and the remaining cases are when size_t is used instead of int for loop indexes), and typically the only operation done on pointers are add, sub and compare. This also affects indexing - some_pointer[signed_int32_offset] tends to show up very often in code, and you probably don't want the compilers to add a sign extension operation every time.