> RISC-V is amenable to a wide array of microarchitectural decisions
As is ARMv8. Applied Micro, Broadcom, Cavium, Huawei, Nvidia, AMD, Samsung and Apple are all architectural licensees with radically different microarchitectural implementations. For example, Nvidia is Transmeta code-morphing style implementation. Also, Intel and AMD continue to innovate in the x86 space.
At this date, RISC-V has no fundamental advantage over any of these architectures and then has the fundamental disadvantage of not having access to their IP. You're lining up against Usain Bolt and your advantage is that you're wearing organic cotton. That's just not gonna work.
NVIDIA's Denver is a feat; I think that if it says anything, it's that ARM's instruction encoding is deficient. AArch64 instruction encoding is less dense than AMD64, and completely lacks compressed instructions (like Thumb). To NVIDIA, it made more sense for them to write a realtime binary translator for an internal ISA which is clearly enabling their microarchitecture more than ARM is.
AMD and Intel spend more money on research than you can even imagine, and it's not surprising that they manage to make x86 machines that lead in single-thread performance, but since Intel tried Itanium, you can tell their designers feel x86 is deficient. I mean, just imagine how much of their chips is just decode.
Also, not to get too childish, but ironically NVIDIA is one of the vendors who is shipping RISC-V in a lot of products. Soon enough, that Denver-style core is going to be sitting on a die right next to a RISC-V. ;- )
That's a good point about Nvidia adopting RISC-V. I didn't know that but for their application it's a good idea.
I'm not a Denver fan and at this point I think we can safely say Code Morphing has been tried. However, I wouldn't conclude that Denver means that ARM's instruction encoding is deficient. The optimizations that Denver provides would be impractical in any ISA.
Moreover architectures are meant to be implemented+optimized in many ways. You may not like x86 but planting that flag in the sand allowed Intel to innovate on the microarchitecture side while developers innovated on the application side knowing that x86 would still be there. It's the same value proposition that IBM offered with the original architecture, System 360.
Where I like x86 and where I don't like RISC-V is that x86 doesn't try to be perfect but rather to adapt over time. RISC-V tries to be perfect and indeed eschews many of the bad RISC ideas from the past (register windows, branch delay slots, tagged integers, ...) while then pig headedly avoiding an obvious feature shared by both x86 and ARM, condition codes. I've read their argument and found it unconvincing. Original ARM had way too much condition code support. I think ARMv8 strikes a nice balance that RISC-V should have followed.
The HP+Intel Itanium effort allowed AMD to propose their AMD64 extensions. That's been quite successful. I wish they'd taken the opportunity to trim more cruft. When ARM went 64b with ARMv8, they took that opportunity and the result is quite clean. I prefer it to RISC-V although I haven't written any RISC-V assembly.
ARMv8 tries to be a good instruction set architecture. To me, RISC-V tries to be the platonic ideal RISC ISA. I'll go with good.
Yeah, I agree that condition codes (and offset loads) are features, not bugs in x86 and ARM; also ARMv8 shows an effort to reduce the number of instructions which can respond to condition codes. Chris Celio has talked about some interesting ways to make up for the lack of these two features, and it seems quite convincing. If you're using the compressed instruction set (which all desktop/workstation type RISC-Vs and most microcontrollers support), then the decoder can implicitly fuse the add and the load, or various forms of conditions, and treat them as a single operation. AFAIK, the compiler backends already try to order the instructions to exploit this.
And yeah, I'm not utterly convinced by any argument about "purity" in ISAs, but in this case there's no question that it has helped a wider variety of people develop interesting and competitive chips in less time.
ARMv8 is a considerable step up in many ways from ARMv7 and earlier, but AArch64 retains user mode compatibility with ARMv7, which means that the more different AArch64 is, the harder it is to implement. In this way, every ARMv8 is also an ARMv7 (of course, sans all the supervisor/hypervisor instructions).
In many ways I like x86, and for the most part I like the vendors. I love that x86 has given Intel and AMD the opportunity to innovate so dramatically.
But just for a moment, imagine that instead of just Intel and AMD, the whole industry can put that same flag in the sand and have just one general purpose instruction set family.
You could have an 8088, a Cortex M0-M4, an ARC, an AVR, a PicoBlaze, a MicroBlaze, a SuperH, a MIPS, a Power, a LatticeMico, etc. but many of these architectures survive today because of a differential in licensing cost with ARM, not because of any technical prowess (and some of them are better in some ways, don't get me wrong!). Imagine that for the vast majority of these people, one ISA family would suffice, and the whole market could compete to bring new performance, power, and cost profiles to each market served by these cores. Then imagine that that same industry can easily start scaling up their designs to compete in the application processor market, and then perhaps in the workstation and server market, then perhaps the HPC market.
Just a thought though, I can't predict the future with any degree of certainty. I just think RISC-V is a whole lot more practical than you might think, just perhaps for people who have slightly different values from you (or from me, for that matter).
I think there's a lot of promise in that it is becoming the standard teaching ISA for universities throughout the United States, Canada, India, and elsewhere.
If there is a generation of new computer engineers coming out of school with research-grade FPGAs in their hands, and their thesis work can be commercialized in a matter of months rather than years, then you can imagine that there will be huge commercial output in RISC-V whether it catches on now or then.
I think that's when it will start to seem more attractive to you, there will be more investment in it and you can see some clear, immediate benefit aside from cost savings and licensing flexibility.
Based on these photos, I’d estimate instruction decoder takes about 10% of each core, and about 7% of the whole chip.
For Intel I was unable to find similar pics, but my estimation is 3-4% of the chip area. The instruction set is the same; the complexity should be comparable. But most Intel chips have like 50% of the area occupied by integrated graphics.
The micro-op cache size increased to 2048 from Intel's 1536 μops. His testing shows 5 instructions per clock cycle up from Intel's 4. There are limits to the ILP a scheduler can find; more in one area means more demand in another. This is no mean feat for AMD to pull off.
You're right, but key words here are "At this date". What you said could have been said exactly in the same way about Linux against commercial Unices about 15 years ago. It's a long game here, and we're only in the early phase. And it may not take that long, but we'll see.
Regarding technology, just as Linux initially the key is not having a technological advantage, but being cheaper and good enough. The improvements can come later, when the ecosystem gets bigger and more resources pours in.
RISC-V is thrown around like if it's an already working CPU but it is not. It is just a document describing an ISA, you can't compare it to Linux, it's a completely different thing.
There are a lot of costs in implementing an ISA and that includes: design, functional verification, physical implementation and software testing. All those steps together will require hundreds and hundreds of engineers, many expensive tools and thousands of man-hours. And once you are done, you will need to find be careful not to violate any patents while shipping your CPU to the end customer.
By paying a license fee to ARM, you get all these steps done for you plus with support.
Linux is something that you can download from kernel.org, compile overnight and get it booting right away. RISC-V is something that you need to build yourself.
When I did a presentation on RISC-V last year I counted 6 real implementations (full custom ASICs). Now granted only one or two of those you can buy, the others are research projects, but they do exist and they did produce real silicon. This year we should see a couple of 64 bit implementations, which is when it'll get really interesting.
There are of course multiple FPGA implementations (I have one about 2 feet away from me now), but they are very slow.
What kind of for free are you talking? The first commercial run RISC-V microcontroller SoC has fully-published RTL, and a company which will support you in adding it to your products (SiFive). Obviously people aren't going to give you the manufactured chips for free, but how close do you want it?
Linux didn't instantly become something you could download from kernel.org, compile overnight and get it booting right away. It took hundreds and hundreds of developers, thousands of man hours, financial investments from a large number of companies worldwide and many many years for Linux to become what it is today. All of this done while there were several existing commercial Unix variants which could have been licensed instead.
During its early years many scoffed at it as you have RISC-V. "It is a hobby OS. It will never be able to really compete with the likes of Solaris, HP-UX, and AIX. Heck, it won't even be able to compete with SCO and Unixware."
I'm not saying that RISC-V is an hobby project, I'm just saying that hardware development is nowhere comparable to software development.
You need much more support and verification while developing hardware then developing software. And while you can reuse the functional design (please note the keyword "functional"), the physical implementation needs to be redone from project to project.
ARM, Intel, AMD, Apple and Qualcomm have an army of engineers with all kinds of tools that go through all the steps of hardware design and implementation which you can't do as a side project at home using just your computer.
Linux is still a hobby OS. It's not a particularly wonderful example of software engineering. Its only real benefit is that it's free and comes with an ecosystem of other free software that kind of mostly works as long as you don't mind the occasional security horror, and can be used as-is or customised at relatively low cost.
That combination of features makes it appealing in a variety of business cases - for business reasons.
RISC-V can't be customised at relatively low cost. It's nominally free, but the freeness doesn't mean much in a business setting.
The total cost of developing a custom core remains beyond the reach of small companies.
Big companies already know there's an established ARM ecosystem with working compilers and a simple, risk-free, and relatively affordable business model.
"Linux is still a hobby OS. It's not a particularly wonderful example of software engineering. Its only real benefit is that it's free and comes with an ecosystem of other free software that kind of mostly works as long as you don't mind the occasional security horror, and can be used as-is or customised at relatively low cost."
That is complete nonsense. Linux, particularly Red Hat Enterprise Linux is as serious of a server OS as exists in the world today. Companies like IBM and Oracle would never embrace a "hobby" OS in an enterprise setting.
As for "occasional security horrors", sadly there is no OS of any flavor that is immune.
"So what business problem does RISC-V solve?"
For one thing, RISC-V offers the promise of fully open computer systems, without opaque black boxes anywhere providing potential back doors or other problems. The Intel AMT vulnerability is an excellent example of how that can go very wrong:
RISC-V also provides a playground for smaller entities (like university labs) wishing to experiment with innovative new hardware techniques like Unums. That's very valuable in its own right.
> and your advantage is that you're wearing organic cotton.
Open source hardware is not like organic cotton, it's more like having the kitchen, the tools and the ingredients to cook your own awesome meal vs going to a restaurant but never able to make any food yourself.
As is ARMv8. Applied Micro, Broadcom, Cavium, Huawei, Nvidia, AMD, Samsung and Apple are all architectural licensees with radically different microarchitectural implementations. For example, Nvidia is Transmeta code-morphing style implementation. Also, Intel and AMD continue to innovate in the x86 space.
At this date, RISC-V has no fundamental advantage over any of these architectures and then has the fundamental disadvantage of not having access to their IP. You're lining up against Usain Bolt and your advantage is that you're wearing organic cotton. That's just not gonna work.