A (minor) design flaw in RISC-V imo is the size of the floating point register file: 32 fregs is too many, 16 would have sufficed. We wouldn't need 4 major opcodes for fused multiply-add and it would be easier to find encoding space for non-ieee float insns (posits, packed simd).
-
I think it’s probably the other way around. Sixteen registers is usually plenty for integer code, but floating point code can often use all the registers you’ve got. (That might change if you have a vector unit)
I believe that one can easily use all the fp regs available, but does it make a performance difference? (I don't have any data on this, so this is not a rethorical question. :) The cost in terms of instruction encoding space is big imo. Also the area cost of regs file for simd.
-
-
One of the problems with 32 registers, floating point or otherwise, is that you still need to save them on any function call. If you are just going to stuff them on the stack anyway, you might find 16 is just as good.
-
Performance-critical floating point code is usually in leaf functions, so callee-save is best for them. Quite unlike integer code/registers.
End of conversation
New conversation -
-
-
I don’t have anything immediately to hand (my Hennessy & Patterson is 1200 km away) but I’m sure this has been studied. FMAD takes a lot of space, yes, if the destination is encoded independently. The rest not so much.
-
3 bit rounding mode in each instruction also adds a lot to the space occupied by fp instructions.. (but also adds brownfield that can be used for float representations that do not require rounding modes, such as posits)
- Show replies
New conversation -
-
-
I was hoping you had some data on this. Now I need to know!
Thanks. Twitter will use this to make your timeline better. UndoUndo
-
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.