RISC-V formal spec public review
github.com
RISC-V formal spec public review
1–10 of 38 posts
Re: RISC-V formal spec public review
#2Is over.
> The Public Review period is: March 29, 2019 through May 13, 2019
Re: RISC-V formal spec public review
#3Well, this is progress.
I wonder how many counterparts to delay slots, stack windows, conditional moves, and other embarrassments we are inadvertently enshrining. There's nothing like hindsight to make you facepalm. (The crypto extension is my bet ATM for most-likely-to-embarrass. But that's without reading it.)
The only way to approach this project sensibly is to assume every single FPGA produced after some near future point will have at least one, and more typically dozens of RISC-V cores scattered around like the multipliers you see in them now, just to try to be competitive.
Personally, I am banking my enthusiasm for when the Bitmanip extension goes in.
Re: RISC-V formal spec public review
#4Well, this is progress. I wonder how many counterparts to delay slots, stack windows, conditional moves, and other embarrassments we are inadvertently enshrining. There's nothing like hindsight to make you facepalm. (The crypto extension is my bet ATM for most-likely-to-embarrass. But that's without reading it.) The only way to approach this project sensibly is to assume every single FPGA produced after some near fut…
What's wrong with conditional moves? They're good for mispredictable branches, although I liked them better on PPC which had 8 condition/flags registers instead of just 1.
Re: RISC-V formal spec public review
#5Well, this is progress. I wonder how many counterparts to delay slots, stack windows, conditional moves, and other embarrassments we are inadvertently enshrining. There's nothing like hindsight to make you facepalm. (The crypto extension is my bet ATM for most-likely-to-embarrass. But that's without reading it.) The only way to approach this project sensibly is to assume every single FPGA produced after some near fut…
What's wrong with conditional moves? They're good for mispredictable branches, although I liked them better on PPC which had 8 condition/flags registers instead of just 1.
Conditional moves depend on state left over from the last instruction. But when you want to re-order your instructions to keep all your functional units busy, keeping the conditional moves right makes a big mess. They're fine as micro-ops after you've scheduled them all, but are lousy at the ISA level.
Intel and AMD make it work by throwing another 10,000 or 100,000 transistors at it.
It is better to let macro-op fusion hardware identify opportunities to convert a branch-over-move sequence, all by itself. RISC-V is supposed to be all about powerful macro-op fusion.
Clang is really aggressive about generating cmovs. On Gcc you can still use (x & -c) expressions to get nicely pipelined conditional expressions, but Clang stomps them all to cmovs.
Cmov is one of the methods to mitigate Spectre because Intel refuses to speculate loads in them. So, cmov from memory pessimizes your code in cases where you aren't worried what might be sharing your cache.
Re: RISC-V formal spec public review
#6How easy is it to do bigint arithmetic in RISC-V?
Re: RISC-V formal spec public review
#7How easy is it to do bigint arithmetic in RISC-V?
It has perfectly good add and multiply instructions, so uh easy? What at an ISA level would make it hard?
Re: RISC-V formal spec public review
#8How easy is it to do bigint arithmetic in RISC-V?
It has perfectly good add and multiply instructions, so uh easy? What at an ISA level would make it hard?
Connecting from one word to the next. Do you have to do 32-bit multiplications so as to retain the high half of the result, or does a 64-bit multiply deliver the high 64 bits of the result somewhere?
Also there is stuff about the carry from 64-bit addition.
(Substitute 16 and 32, for 32-bit units.)
Re: RISC-V formal spec public review
#9Earlier quoted context omitted.
It has perfectly good add and multiply instructions, so uh easy? What at an ISA level would make it hard?
Connecting from one word to the next. Do you have to do 32-bit multiplications so as to retain the high half of the result, or does a 64-bit multiply deliver the high 64 bits of the result somewhere? Also there is stuff about the carry from 64-bit addition. (Substitute 16 and 32, for 32-bit units.)
[deleted]
Re: RISC-V formal spec public review
#10Earlier quoted context omitted.
It has perfectly good add and multiply instructions, so uh easy? What at an ISA level would make it hard?
Connecting from one word to the next. Do you have to do 32-bit multiplications so as to retain the high half of the result, or does a 64-bit multiply deliver the high 64 bits of the result somewhere? Also there is stuff about the carry from 64-bit addition. (Substitute 16 and 32, for 32-bit units.)
There are instructions to get the top half of a multiply, and a suggested ordering so that the chip can deliver both halves with only one calculation.
There's no carry flag but I'd say it's still easy to work around that.