Agner`s CPU blog

Proposal now published

Author: Agner

Date: 2016-03-30 11:31

Hubert Lamontagne wrote:

it all comes down to what's your limiting factor:
- If your limiting factor is issue width (how many different instructions per cycle you can issue), then multi-result
instructions are good because you're doing more work out of your few available instructions. x86 tends to
fall in this case due to the whole instruction length business, and good x86 designs tend to do lots of work
from few instructions (AMD's 3-issue Athlon is a perfect example of this - and a good example of "fast CISC").
- If your limiting factor is register-file and rename ports, then multi-result instructions are bad because they
won't be faster than multiple instruction sequences and they make the pipeline more complex overall (since
the multiple results have to be committed together and so forth).
- If your limiting factor is L1 cache read and write ports, then it's all a wash.

I believe the limiting factor will most likely be cache bandwidth and memory bandwidth. That's why I want moderately complex and compact instructions.

We need two-result instructions for: add-with-carry,
I don't think ADC is used often enough to warrant being included in a general purpose instruction set.

add-with-carry is used mainly for high-precision math. This is typically big number-crunching algorithms where performance is critical.

overflow detection,
Careful use of comparison instructions handle this case adequately, as far as I can tell. For instance, when doing unsigned addition, you only have to compare the result with a source operand.

Overflow detection with signed integers is a mess.

pop register,
Ok, this one is actually fairly common in general purpose code.

Well, I have changed my opinion on this one :-)
Push and pop will rarely be used in critical parts of the code if my ABI proposals are met. We don't need push for function parameters because we have assigned 16 integer registers and 16 FP/vector registers for function parameters. We could even assign more registers, if needed. Push and pop for register spilling can be kept out of the critical innermost loops and functions if we implement my idea that the register use of functions should be reported in object files.

The problem with push and pop is that a push or pop that is waiting for an operand can delay all subsequent stack operations unless the instruction is split into micro-operations or a special stack prediction mechanism is implemented. So I think that we don't need push and pop instructions at all, but I still want to have call and return instructions that use the stack (for the reasons I have explained in my document). A direct call and return cannot delay subsequent stack operations, but an indirect call can, if it is not split into micro-operations.

read-and-increment-pointer,
That case is similar to pop register: on one hand, you get two results for the price of one if your front-end can
only generate a limited number of instructions (which is why ARM has this instruction), but on the other hand,
separating reading and pointer-increment lets you combine a whole bunch of updates to the same pointer
together, which is often good since it reduces the number of intermediary results for the pointer value

The only reason I want read-and-increment-pointer is to make it easy to save all registers. A "read-and-increment-pointer" can fit into a tiny instruction, while you will need a doubleword (64 bit) size instruction to save or restore integer registers with a non-moving pointer, and you will need two instructions to save or restore each variable-size vector register. So this is for compactness, not for speed. It may be bad for the speed if a compiler uses the read-and-increment-pointer instruction for ordinary loops, unless the instruction is split into micro-operations. Other forms of loop will be faster than read-and-increment-pointer.

Reply To This Message

Previous Message

Next Message