VRoom A high end RISC-V implementation

Re:VRoom A high end RISC-V implementation by throwaway81523 on Tuesday March 22, 2022 @03:04AM (#30763407)

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.

[ Parent | on HN ]

Re:VRoom A high end RISC-V implementation by Taniwha on Tuesday March 22, 2022 @01:58PM (#30769301)

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.

[ Parent | on HN ]

Re:VRoom A high end RISC-V implementation by throwaway81523 on Tuesday March 22, 2022 @05:11PM (#30771613)

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.

[ Parent | on HN ]

Re:VRoom A high end RISC-V implementation by Taniwha on Tuesday March 22, 2022 @05:32PM (#30771845)

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)

[ Parent | on HN ]

Re:VRoom A high end RISC-V implementation by throwaway81523 on Wednesday March 23, 2022 @12:49AM (#30775067)

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.

[ Parent | on HN ]