3 ms·

Do you think it is feasible to add some kind of sticky overflow detection bit for integer arithmetic, the way IEEE 754 specifies for FP? The hope is to be able

Do you think it is feasible to add some kind of sticky overflow detection bit for integer arithmetic, the way IEEE 754 specifies for FP? The hope is to be able to efficiently implement checked arithmetic as required by e.g. Ada. It came as a real disappointment that RiscV seems to have made that harder rather than easier, compared to the x86 and its ilk. The sticky bit is hopefully more efficient than traditional condition codes, since the compiler can emit checks for it at the end of a function or basic block, giving the hardware some time to catch up.

Taniwha 5y ago
RISCV doesn't have condition codes, which makes building systems like this with lots of ALUs a lot easier, everything happens in the registerfile and the renaming system. It does have 'sticky' state bits for FP and I can see how I'll implement them - the big problem is not setting them (because they can be accumulated in any order as instructions hit the commit stages), it's how you test them that effectively becomes a synchronising point in a pipe where you spend all your time trying not to do that - everything has to stop and line up in order before you can sense that state reliably.
- throwaway81523 5y ago
  Right, the idea of the sticky bits is that you can execute a number of instructions before hitting a sync point, as compared with traditional condition flags or exceptions which have to potentially sync on every instruction. The hope is for that have less effect on performance. I don't know if it causes issues with modern FPU's. Are imprecise exceptions (like on some old machines) still a thing? I wonder if there is a way to record the exception info so its origin can be reported even if it is not noticed til later.
  - Taniwha 5y ago
    If you don't synchronise it's not an issue :-) but if you have 100+ instructions in motion at any one time creating a bottleneck at the end of every basic block would likely have a big effect on how things run. Normally we retire up to 8 instructions per clock - merging 8 bits of sticky state is some simple logic (some or gates, it doesn't matter what order they get processed in), merging 8 saved PCs (which one do you save?) is harder, it probably means a priority encoder (order probably does matter) and a 63 bit mux (still doable in a clock though)
    - throwaway81523 5y ago
      Ah, well, you're better equipped than I am to figure this out. Anyway the FPU will have to deal with it. Maybe if the big float computations are mostly vector ops, though, that will help.

Taniwha 5y ago

RISCV doesn't have condition codes, which makes building systems like this with lots of ALUs a lot easier, everything happens in the registerfile and the renaming system. It does have 'sticky' state bits for FP and I can see how I'll implement them - the big problem is not setting them (because they can be accumulated in any order as instructions hit the commit stages), it's how you test them that effectively becomes a synchronising point in a pipe where you spend all your time trying not to do that - everything has to stop and line up in order before you can sense that state reliably.

throwaway81523 5y ago
Right, the idea of the sticky bits is that you can execute a number of instructions before hitting a sync point, as compared with traditional condition flags or exceptions which have to potentially sync on every instruction. The hope is for that have less effect on performance. I don't know if it causes issues with modern FPU's. Are imprecise exceptions (like on some old machines) still a thing? I wonder if there is a way to record the exception info so its origin can be reported even if it is not noticed til later.
- Taniwha 5y ago
  If you don't synchronise it's not an issue :-) but if you have 100+ instructions in motion at any one time creating a bottleneck at the end of every basic block would likely have a big effect on how things run. Normally we retire up to 8 instructions per clock - merging 8 bits of sticky state is some simple logic (some or gates, it doesn't matter what order they get processed in), merging 8 saved PCs (which one do you save?) is harder, it probably means a priority encoder (order probably does matter) and a 63 bit mux (still doable in a clock though)
  - throwaway81523 5y ago
    Ah, well, you're better equipped than I am to figure this out. Anyway the FPU will have to deal with it. Maybe if the big float computations are mostly vector ops, though, that will help.