Agner`s CPU blog

I can see the following possibilities for implementing 2-output functions:
1. Use one instruction with two output registers.
2. Use two separate instructions, possibly executed simultaneously, one for each output.
3. Use two elements of a vector register.

Method 1 would certainly be the most efficient and straightforward solution. We just have to weigh the hardware costs versus the benefits.
Method 2 is less efficient. For example, for integer division, you cannot make two divisions simultaneously, or even pipelined, unless you double the hardware.
Method 3 might be an efficient solution for a scalar add-with-carry chain, but for other purposes, it will complicate the software when you have to split and join data into vector elements. It becomes more complicated when you want to vectorize vectors. You may use even-numbered vector elements for addend and sum, and odd-numbered vector elements for carry. This will complicate both hardware and software, and the throughput will be half of what you would get with method 1.

Instruction length:
As I argued before, you need 32 bits for address offset, so you must allow instructions of two 32-bit words.

Many instruction sets don't allow big immediate constants. For example, to load a 32-bit constant you need a memory operand with a 32-bit offset. My argument is that it is more efficient to have a 32-bit immediate operand than a 32-bit offset to a 32-bit memory operand. This will reduce the loading on the data cache. Remember that cache misses are very expensive.

In my analysis I found that you may need instructions of three 32-bit words to accommodate all the bells and whistles of vector instructions with a memory operand, variable vector length, mask, etc. There may be more needs for long instructions in the future as new features are invented. At least the current trend goes towards putting more features into a single instruction to get higher overall performance. This is the reason for my decision to allow instruction lengths of one, two and three 32-bit words. This is certainly a compromise, since instruction length decoding becomes more expensive the more different instruction lengths you have.

If we decide to allow an instruction length of 3*32 bits then we can afford the luxury of allowing immediate constants of 64 bits, for example a double precision float or a 64-bit absolute address.

On the other hand, if we limit the instruction length to 2*32 bits, then there will be certain instructions that cannot have a memory operand with 32-bit offset, and we will need two instructions to load a 64-bit immediate constant. This would still be a viable solution, but I suspect that a patch would be added in the future when the need for more instruction bits arise as more features are added. Remember how many patches have been added to old instruction sets.