3 ms·

> Any hardware adder provides almost for free the overflow detection output (at less than the cost of an extra bit, so less than 1/64 of a 64-bit adder). So any

> Any hardware adder provides almost for free the overflow detection output (at less than the cost of an extra bit, so less than 1/64 of a 64-bit adder). So anyone who thinks about an efficient hardware implementation would expose the overflow bit to the software. Ah, but where you do put that bit that you got for free? A condition codes register, global to the processor / core state? That worked terrific for single-issue microcontrollers back in the 1980's. Now you need register renaming, and all the expensive logic around that to track which overflow bit is following which previous add operation. That's what's being done now for old ISAs, and it generally disliked for several reasons (complexity being chief among them). Well, you could stuff that bit into another general purpose register, but then you kind of want to specify 4 registers for the add command. Now where are the bits to encode a 4th register in a new instruction format. RISC-V has room to grow for extensions, but another 5 bits for another register is a big ask.

imtringued 5y ago
I have no clue about flags but why not just store the flags with the register? Each register would have 32+r bits where r is the number of flags.
- ansible 5y ago
  > I have no clue about flags but why not just store the flags with the register? Each register would have 32+r bits where r is the number of flags. That sort of design can be done, but that just pushes the problem around. Let's look at the original ARM 64 bit code: adds x12, x6, x10 adcs x13, x7, x11 The second add with carry uses the global carry bit, it isn't passed as an argument to the adcs instruction. So if you store the carry bit with the x12 register, you would then need to specify x12 in the adcs instruction on the next line. So you need a new instruction format for adcs that can specify four registers. You could change the semantics, where the add instructions use one register as the source and the destination, like on x86-64, but that's a whole 'nother discussion on why that is and isn't done on various architectures.

imtringued 5y ago

I have no clue about flags but why not just store the flags with the register? Each register would have 32+r bits where r is the number of flags.

ansible 5y ago
> I have no clue about flags but why not just store the flags with the register? Each register would have 32+r bits where r is the number of flags. That sort of design can be done, but that just pushes the problem around. Let's look at the original ARM 64 bit code: adds x12, x6, x10 adcs x13, x7, x11 The second add with carry uses the global carry bit, it isn't passed as an argument to the adcs instruction. So if you store the carry bit with the x12 register, you would then need to specify x12 in the adcs instruction on the next line. So you need a new instruction format for adcs that can specify four registers. You could change the semantics, where the add instructions use one register as the source and the destination, like on x86-64, but that's a whole 'nother discussion on why that is and isn't done on various architectures.