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).
-
-
Replying to @oe1cxw
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)
2 replies 0 retweets 2 likes -
Replying to @BruceHoult
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.
3 replies 0 retweets 1 like -
Replying to @oe1cxw
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.
1 reply 0 retweets 1 like -
Replying to @BruceHoult
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)
2 replies 0 retweets 0 likes -
Replying to @oe1cxw
Anyway I don’t see this as an issue for RISC-V given that there is not only a lot more free space available in the 32 bit encoding than other RISCs (just look at Aarch64!), but also the entire 48 bit, 64 bit and larger encodings.
1 reply 0 retweets 1 like
Well I said in the OP that it is only a minor issue.
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.