4 ms·
>> But ultimately, the gist of their argument is this... Funny, I thought the whole thing was bitching that RISC V has no carry flag which obviously causes mul
by phkahler 5y ago
>> But ultimately, the gist of their argument is this...
Funny, I thought the whole thing was bitching that RISC V has no carry flag which obviously causes multi word arithmetic to take more instructions. The obvious workaround is to use half-words and use the upper half for carry. There may be better solutions, but at twice the number of instructions this "dumb" method is better than what the author did.
Flags were removed because they cause a lot of unwanted dependencies and contention in hardware designs and they aren't even part of any high level language.
I still think instead of compare-and-branch they should have made "if" which would execute the following instruction only if true. But that's just just an opinion. I also hate the immediate constants (12 bits?) Inside the instruction. Nothing wrong with 16 32 or 64bit immediate data after the opcode.
I hope RISC 6 will come along down the road (not soon) and fix a few things. But I like the lack of flags...
- kortex 5y agoSo if I'm understanding this particular tussle correctly, carry flags are problematic for optimization because they create implicit mutable shared global state, which isn't necessarily reflected in the machine code. Risc-v basically says "lets make the implicit, explicit" and you have to essentially use registers to store the carry information when operating on bigints. Which for the current impl means chaining more instructions. Is that correct? That sounds like what the FP crowd is always talking about - eschewing shared state so it's easier to reason about, optimize, parallelize, etc.
- R0b0t1 5y agoThere's more options than just a global carry flag, like a n+1th bit on each arithmetic register. Actually, that is how I assumed they would implement it.