Will RISC-V Revolutionize Computing?
m-cacm.acm.org
m-cacm.acm.org
I can see how RISC-V works for SoC designers who either 1. Want to cut costs to a minimum or 2. Want to add their own proprietary extensions to distinguish it from the competition. I'm less sure that it works for everyone else.
The instruction set running on your Raspberry PI is the same as that running on your iPhone which in turn is the same as that running on an Ampere Server. Do we really want to be faced with a multiplicity of distinct ISAs?
The compiler abstracts the instruction set for most people.
I don't think it's reasonable to expect compiler writers to solve any fragmentation issues.
As I said I like RISC-V and think it's laudable. We just need to recognise the downsides and not get too carried away.
There exist excellent and free / open-source tools for dealing with this kind of inconvenience.
Even then, is it worth it? IMO, yes, because screw having to pay and get blessings for the legal right to merely execute an instruction stream on a processor of your own design.
However, the possible fragmentation issues are a concern, but mainly within the RISC-V ISA itself with all the extensions that will probably start popping up.
RISC-V isn't 'GPL' in any meaningful sense so the danger is that we effectively see a series of 'forks' by the most powerful SoC designers - they add their own instructions etc and use their designs to crowd others out. What if Apple and Samsung together forked ARMv8 added its own instructions and everyone started writing their code for that variant because of their market power?
I understand why ARM isn't necessarily the most popular firm and why the fees / control aren't ideal but I do think its important to think through the full implications of any market change like this.
If we take that notion as the gospel truth, there is no part of the computing stack that can survive as a stable, uniform standard, including the base architecture.
But computing as a whole is resilient to such changes. Having a special hardware instruction is a competitive advantage if it's used, but it tends to exist as implementation detail and doesn't carry the weight of an end-user feature. A chip design can target some subset of applications, but software fallbacks are expected, and software developers increasingly don't attempt to optimize to the hardware, making it a commodity.
In that light RISC-V arrives at a time where it's very unlikely to matter. A decreasing share of applications will need to look that deeply.
Yes! My computer already have lots of them (GPU, Network-card, SSD-Controler, Intel-ME (ok bad example) and so on)
Do YOU have to maintain the codebase of your operating-system?
If you want to know howto maintain Code for multiple ISA's ask netbsd and openbsd.
My underlying point was that there are trade offs - more architectures - great for some but a lot more work for others.
I'm sure the BSD's go a great job supporting lots of architectures - but they represent a small part of the overall software ecosystem.
Well its an OS, and by the definition the Software that has the most dependencies ISA wise, and it's kind of 'easy' to bring it to another architecture.
>No but I do have a codebase to maintain and the more architectures the more work!
Depends on your Software and your Language...sure can be more work, but supporting multiple OS's, Databases, Filesystems too.
Yes. We want distinct ISA where it makes sense for the application. You want to have little sensor controller, should it really be the same as a gigantic parallel server?
RISC-V deals with this by creating 'profiles' meaning specific configurations that apply to applications of a particular field.
And of course the tools of RISC-V should be designed to handle these situations.
People are talking about cost of licensing, but the cost of ARM are peanuts compared to cost of design and fabrication. I am not even sure if the word peanuts correctly describes it.
ARM has made changes that you no longer need some one-off fees before you start producing "certain" ARM design. You get access to it and only paid for it once you start making revenue.
RISC-V makes sense for tiny microcontroller that ships in tens of millions. Western Digital saves millions every year just by switching to RISC-V for Microcontroller used in their HDD.
RISC-V's main competition is the like of ARC and some other DSP. It is competing with ARM in certain segment ( or the old ARM embedded segment ). But it is not competing ARMv8.
No argument that RISC-V is both interesting and has a lot of value. Just not that enthused by the "a new golden age" and "will eventually supplant x86 and ARM" commentary being presented (primarily) on the basis of ISA customisation without a broader discussion of the pros and cons and wider market issues.
It would be quite a lot like RISC-V, except it would:
- have rotate instructions in the core set
- have popcount instructions in the core set
- represent bool `true` with ~0 in the ABI
- have all the add, subtract, and comparison instructions set two registers (in addition to the destination), one to 0 and the other to ~0, according to a test of the result.
- have conditional branch and conditional move designate a register to be tested for equality to zero. Conditional move would move from one of two register sources, either of which could be the same as the destination.
- have two ISA registers fixed at 0 and -1.
So `true` would be 0xFFFFFFFF (assuming 32 bit)? Can you explain the advantage of that? Presumably 0 through 0xFFFFFFFE would be considered false?
The merit in `true` being 0xff...f is that, ANDed with X, it yields X. We see this logic applied with resounding success in GPUs and AVX instructions, where a multiword comparison sets corresponding lanes of a destination register to all zeroes or all ones. It is nothing short of bizarre that RISC-V architects (apparently) never heard about this.
In RISC-V, the instruction that sets a register to the result of a comparison sets it to 0 or 1, but 1 is (almost) useless. It has to be negated, and often then copied and inverted too, before it's useful.
a = (x & c) | (y & ~c)
Personally I'd probably be just as happy with operations that spams the first bit out to a full word, along with ANY / ALL to reverse that; but I'm with ya, this is a really important consideration.
> is a branch-free conditional assignment, and only works with c = 0 or ~0.
Using this hack only makes sense if there is no "conditional move". But the bitmanip risc-v extension offers a "conditional move" (cmov) [1]. With the addition of this operation there's no longer a need to use "0/-1" instead of "0/1".
[1]: https://github.com/riscv/riscv-bitmanip/blob/master/bitmanip... page 36
PS: You may notice that there's also an operation (cmix: conditional max) to do what you're suggesting: rd = (rs1 & rs2) | (rs3 & ~rs2) Which allows to mix the bits of two registers.
The notion that basic bit manipulation primitives are an obscure optional feature is a serious problem in the RISC-V process.
That's the whole idea of an extension. You may or may not include it depending on your needs.
> And there are no bitmanip extensions in any existing chips
RISC-V is a big project, and it is not yet complete. Some extensions are completed and some are not. The bitmanip extension is not finished yet, so it's understandable that it hasn't yet been integrated into chips.
> may never be in any future chips
Where did that statement come from?
> The notion that basic bit manipulation primitives are an obscure optional feature is a serious problem in the RISC-V process.
Bit manipulation is not an "obscure optional feature", but an "optional feature" just like the other extensions.
Please explain why this is a problem?
You're just blaming RISC-V without any argument there.
It sounds like you've identified a niche that isn't filled -- perhaps you could "corner the market" taking advantage of the SkyWater / Google offering. A risc-v microcontroller with the bitmanip extensions would be very cool, and its existence could prompt compilers to start targeting it. Go for it!
rotate is essential to modern crypto ciphers and efficient hashes.
> - have popcount instructions in the core set
There is the Bitmanip extension for that. Why it should be in the core ISA ? Microcontrollers don't always need it. The purpose of the extensions is to keep the core ISA as minimal as possible.
> - represent bool `true` with ~0 in the ABI
It only takes one operation to emulate this behavior when you need it. addi rd, rs, -1 (you also have to flip the comparison, but it doesn't cost anything) Can you justify that we need "0/-1" more often than "0/1"?
> - have all the add, subtract, and comparison instructions set two registers (in addition to the destination), one to 0 and the other to ~0, according to a test of the result.
Why ? Adding destination registers puts more pressure on the register bank and may limit future CPU designs. Do you have an argument to show that it's worth it despite the price?
> - have two ISA registers fixed at 0 and -1
Which piece of code would benefit from that? A good justification is required to remove a (non-constant) registre from the ISA. Anyway, RISC-V already allows you to do that. Just write "addi rd, x0, -1" at the beginning of your code then use the rd register as a -1 register.