RISC-V isn’t as interesting as you think
sporks.space
sporks.space
(1) There are several royalty free implementations, ranging from the minimal (PicoRV32) to widely-used embedded (Rocket) to reasonably high-end (BOOMv*). There are also proprietary implementations, and this is how it should be.
(2) RISC-V has defined various platform specifications which means in practice ISA fragmentation is not going to be a thing. The platform will define the minimum set of extensions, and the rest will be probed at runtime (which is exactly the way x86 works).
(3) About economics - the author ought to read some Clayton Christiansen, or maybe take a look at how companies like Intel, AMD and Arm came to prominence.
(4) Yes, open spec != open implementation, but see point (1).
(5) RISC-V has been designed by experts in the field and adopted by some very large hardware companies with experience and who ship in very large volumes (millions and billions of chips). It may well not be perfect, but it doesn't need to be in order to be successful (see also x86).
High-end means building and optimizing miroarchitecture to specific node and prosess technology. Typically it costs $100-200 million to do and it's not high-end after 3 years after anymore.
(The experience of Intel's Itanium, IBM's Cell processor and many others shows that it's not enough to have a few good ideas but you have to have ZERO bad ideas that slow you down to get a high performance design.)
Just doing something about the one potential bottleneck that you feel like doing something about doesn't necessarily get you a gain in performance at all.
The idea of scheduling parallelism in the compiler (VLIW) doesn't work for mainstream workloads because the time it takes for data to come back from the DRAM is highly variable.
A super-scalar processor can possibly run some instructions at the hardware level while other block wait until data gets back from DRAM.
A VLIW processor packs N instructions together (say N=3) and if one of them is blocked by DRAM, they all block. (If one of them is blocked by Optane they all block for a very long time...)
It looks obvious in retrospect but it's amazing how most of the RISC workstation vendors missed it and put themselves out of business by getting on the Itanic train.
(VLIW is successful for DSP and GPU, but that's because workloads like that can have completely predictable fetches)
I don't know what the problem w/ Cell was exactly, but it was the same in that it couldn't pull data from DRAM fast enough to keep the silicon busy.
Also Itanium was a heavily superscalar design; I think you meant out of order.
Cell just plain didn't really let you directly address main RAM, so you never saw unknown DRAM accesses stalling the cores. Access to the local memory was always single cycle.
In neither case was unknown RAM latencies an issue with the design.
And time to market is quite important in this area.
- ARM might license you cores for years and suddenly stop
- you might want to switch to a different vendor but all your code, tooling and knowledge is locked-in
- there is no guarantee that ARM will negotiate with you. Especially true for small companies, community projects, embargoed countries.
- ARM will not allow to relicense their "IP" to 3rd parties, either paid of for free
It has some comparisons so you can judge for yourself. Of course, since this is a project driven by only 2-3 grad students it isn't completely fleshed out. However, you would assume that if the ISA just wasn't suitable for high performance implementations that a project like BOOM would have uncovered that by now.
I don't think there was ever a commercial goal in mind.
Multiplications and divisions happen out of band on most chips (that is, on the side) because they take so many clock cycles to complete. All the extra synchronization takes a lot of extra work.
The RISCV ISA is seeing an uptick in the embedded space where it can be very efficient in core size and thus cost. Here too, requiring those units would hurt the market. Meanwhile, it can reasonably be assumed that any desktop-grade CPU will have those extensions just like it’s assumed that desktop x86 chips all have SSE.
Speaking of that, there are over twenty x86 extensions released since 2000. There are 8 or so in just the last 5 years. Despite this, life goes on because the tools that make handing this easy have existed for decades.
Never mind what RISC-V says about itself. Here is Dave Jaggar, a key ARM architect, endorsing RISC-V as state of the art in 2019: https://youtu.be/_6sh097Dk5k?t=51m10s.
I'd love to see the result of a concerted ground-up creation of a hardware and software system that starts from scratch and leaves unresolvable legacy considerations to virtual machines or whatever.
Anyway, totally Off Topic, but thanks for what I'm assuming will be my watching that entire video!
The entire effort of supporting it and building the ecosystem will be hard to justify economically at these cost figures.
Mill on the other hand has a lot of interesting ground-breaking ideas that can potentially offer a 10x performance/watt improvement.
Many people have been recently in awe after experiencing the ARM performance improvements around 40% offered by the Apple silicon and AWS Graviton CPUs. Just imagine something offering a 10x based on a Mill design, I'd love to see it built one day and available on the market.
This has been tried often. (Thinking Machines, Multiflow, e.g., not to mention Itanium) I would love to see this too; I worked for a startup that tried to do this (vliw, no specex), and taped out with a working chip, after 6 months. Maybe the startup didn't have the right sales team, but they didn't manage to make any meaningful sales, the culture in the buyer's market is too conservative.
In the case of the company I worked for I suspect that part of the problem is that conservative buyers will look for excuses to say no, instead of excuses to say yes. One such example is that nobody would accept that you could move specex to the compiler, with the old "sufficiently advanced compiler" joke, despite the fact that they could prove that llvm was "advanced enough".
Your post in interesting. I agree yet disagree. You got the context correct but he explicitly said 'it's the standard now for 32 bit general purpose instruction sets and it's got the 16 bit compressed stuff. Learning from the best still'.
Standard =/ state of the art but in this context, he's stating that learning from the best (state of the art CPU designs) is by learning RISC-V.
One doesn't say something is a standard and state of the art in one breathe, to somehow believe that they're doing something outdated or from 1991's knowledge base.
I think you're interpretation of his message would need to have further explicit statements from him to support your claim (that somehow 'state of the art' doesn't mean for CPU design, instead of just learning CPU design).
The listener would be better suited to follow @seedless-sensat's (and my) understanding because there is no evidence to the contrary of what we're stating. The speaker intended both (but if you can find evidence to support your different thesis, I look forward to investigating it further).
Sorry, couldn't resist a well-assembled pun.
Anyway - Extensions based on a minimal subset allow for fragmentation. Yes. Which is probably intended? This can become a problem. Yes. Therefore it should be possible to declare a use case like "all purpose computing" (personal computer) and define a required superset with specific requirements. e.g. RISC-V "Personal Computing Rev01" shall support the following extensions {list}
And please tell me why a closed source, patented, licensed ISA would be better instead of just saying it's open and therefore fragmented and bad.
PS: Insert here the usual "What's about" for Intels notorious CPU-Extensions or ARMs track of compatibility.
Calvin Buckley: https://cmpct.info/~calvin/
May be I'm biased because I learned computer architecture at my university reading Computer Architecture a Quantitative Approach (in 1995, yes I'm old).
This a long and very detailed book with lots and lots of data about tradeoffs in ISA design.
The authors of this book created MIPS and then RISC-V so it's not just academia-only data.
I would love to hear about people who really have done their homework and say with this different RISC-V design over a few thousands tests of various linux/bsd tools/software we gain X% on Y metric. With an open source simulator and tooling provided to verify the claim.
But I think it's mostly talk is cheap (and cheap money from competitor interest ...).
End of rant.
RISC-V is extensible. If someone really believes that more complex addressing modes are worth it then they can add them as a custom extension. If their chips work out to have better performance/price, performance/area, performance/energy then everyone else will want to copy them and those more complex addressing modes will become a standard extension for RISC-V.
There is no sign of the RISC-V community (as opposed to ARM or x86 fans who aren't using RISC-V anyway) moving in that direction.
With the US-China tech war that has obviously changed.
The US has demonstrated an ability and a willingness to prevent China from using highend fab and ARM thus forcing China to invest massively in chip production.
That is why RISC-V with its free ISA has its moment now.
Not because it is novel from a technical perspective.
If I understand correctly, it wasn't really trying to be technically novel. RISC-V wasn't mean to be a research ISA experimenting with interesting new ideas, it was meant to be a decent Free and Open ISA using modern but established design principles.
> The plan was to help both academic and industrial users.
Practicality seems to have been a goal from the start, unlike DLX/MIX/MMIX which were primarily intended for teaching.
If your goal is maximum performance, and general purpose platforms, then it's not very interesting at all. You dont want RISC-V in your PC, but you do want it in your toaster.
RISC-V deserves hype, but that hype should be confined to what RISC-V is good at, not convince you that RISC-V will kill every other ISA.
Why not? Isn't the Apple M1 showing exactly the opposite?
why Apple M1 and AWS Graviton is based on ARM? if ARM license cost is a concern. even smaller players use ARM as well...
Apple probably spent billions to make M1. If someone made the same investment with RISC-V they could get the same results -- the main company currently pushing higher performance RISC-V (SiFive) has total funding of under $200m so they clearly don't have billions to spend. They've got an announced CPU (tested in FPGA) with ARM A72 level performance. That's only about five years of very incremental performance improvements behind (non-Apple) ARM.
pretty much the same thing one does with any other exotic hardware- install a niche unix variant, then proceed to stare at 'top' and 'show registers' output in the debugger while fantasizing about how cool it is and fixing programs that don't build on it yet :)
A PIC or ARV etc can really never be a high end machine. And something like a modern 0x86 would really never be low end either. A small aside legacy processor cores on modern CMOS can do fast bit twiddling while consuming trivial amounts of power and die area.
Where RISC-V can show its value is in the IoT / Embedded markets. There are not high requirements for speed or efficiency, cheapness and ease of integration is going to win out there. If RISC-V can win in those markets the designs made using it can improve over time to take on markets with higher requirements.
If RISC-V can out-ARM ARM, it will probably have a similar long term trajectory.
The design of the compressed instructions is also much more elegant than ARMs Thumb instructions, which was reasonably dropped for 64-bit ARM
Can you help me correct my understanding of the situation if that's where I'm wrong or what additional details I may be missing? I'm not a CPU architecture expert by any means - just an enthusiast.
RISC-V instructions can be exactly two lengths: 2 bytes or 4 bytes. You can tell how long an instruction is by looking at the first 2 bits: 11 -> the instruction is 4 bytes long, anything else (00, 01, 10) -> the instruction is 2 bytes long.
These things are so different that you can't just say "oh, they're both variable length".
Also, the 2 byte instruction in RISC-V are completely optional. They each exactly duplicate some 4 byte instruction. If you want to build an 8-wide machine like the M1 and you think having two instruction lengths will make that too hard -- you can just use the fixed length RISC-V base instruction set instead. The only downside is your programs will be a bit bigger, and you'll need to compile your own software (as Apple, for example, does).
So x86 implementations start to decode at [n, n+1, n+2, n+3, etc.] bytes. Then if turns out that, say, the instruction at offset n was 2 bytes, throw away whatever work was done for decoding at n+1 and continue decoding the n+2 etc.
For RISC-V with the C (compressed) extensions, instruction boundaries are 16-bit aligned, so you can do a similar strategy like above for x86 except you speculatively decode at offsets [n, n+2, n+4, etc.]. See e.g. the SonicBOOM paper.
Of course, speculatively decoding instructions only to throw them away costs power. I have no hard numbers, but I do wonder why RVC didn't specify that an "instruction bundle" is 32-bit aligned and consists of either a 32-bit instruction or a pair of 16-bit instructions? That would have made decoding simpler, though at a cost of worse density.
The problem with this approach is that you get more and more such wasted decoding effort when you try to make a wider decoder. Then again, uop caches exist for a reason and generally work well, they are an excellent choice if you have a hard to decode ISA.
I presume because decoding is already plenty simple, but density always helps.
With RISC-V, compressed instructions are still 16 bit, and all instructions are 16 bit aligned. Further, the instruction length is fully determined by the first two bits in the instruction (11₂ for 32 bits).
For an 8-wide decoder, this means routing is fully determined by 15 bits, after a single AND reduction, this can be expanded early during a fetch pass, the worst case is an 8-way MUX for the last instruction, and even doing decode fully in parallel at every possible offset would at worst require interleaving eight 32 bit decoders with eight (much simpler) 16 bit decoders. None of that really matters a great deal since RISC-V is so trivial to decode.
x86 is an old design, but why did Intel design it this way?
Intel have had quite a few ISAs and all the famous ones are bad, so there doesn't have to be a good reason beyond that.
Hah! Imagining what die size a 40μm process might need to make a CPU. The Intel 8008 (1972) was 10μm.
The above is moving to electronic, but paper still has advantages over electronics so it isn't dead.
I’m hoping for an open source implementation that can be backed by a company or crowdsourced, manufactured at scale and auditioned by the community.
This could happen this decade and would be transformative.
Heck, even being capable of printing replacements for 6581/8580 (SID - sound chip from Commodore 64) or 6526 (IO chips used in the C64 and others that were notorious for burning out) would get a whole lot of retro-enthusiasts excited, as there are a bunch of FPGA reproductions of the SID which are way overkill.
Doing that would be possible by matching processes that were getting dated by 1980...
Beating the fabs at their own game? Not likely. But maybe another game, probably.
I imagine you could put down a "wire" of metal atoms without too much trouble. Something like a capacitor shouldn't be too difficult if you could put down a dielectric.
Not sure about how to do a transistor - maybe there could be an alternative "switch".
Yeah, I'm hand-waving. And maybe the metal substrate an STM uses is a non-starter.
But still, atomic precision seems to be in hobbyists reach and I imagine SOME approach to low volume tiny circuits are possible that would not be economically viable in terms of RnD and fab for "big silicon".
STMs are very limited though. The kinds of atoms you can pick up are pretty limited afaik.
Give it a couple of years, maybe 5-10, and there will probably be hobbyists moving atoms around. The industry and academia will, of course, probably be further along.
I remember reading a book about organic farming that made a great point:
(paraphrasing)
As a home organic gardener you might think that you can't compete with a commercial farmer, but... Say you want to make a tomato dish. You want the most succulent tomato with the softest skin. The commercial farmer needs to choose a variety that has a skin though enough to pick mechanically or by rough hands.
At home you can go as soft as you want to. You can pick it and cook immediately.
The commercial farmer needs to use a variety that can be picked green and ripened.
Etc.
Different scale, different constraints, different opportunities.
As for manufacturing, I think it's harder but not crazy harder. Small batch fabs making small vendors' customized implementations seems reasonable. It's really about reducing requirements for big scale. ISA is one.
I do now almost nothing about the state of today’s CPUs, only that they are extensively complex with long pipelines and that branch prediction is a thing. Also, several layers of caches. x86 on top is almost only an API which frees the hardware engineers from backward compatibility, since these intricacies are programmed by microcodes that are not really accessible to general software.
My question is, wouldn’t a “dumber” processor be better with a more expressive “API”, with instructions like prefetch, some form of parallelism (so that pipelines can be created with machine code and not just heuristics), since it is probably easier and better to branch predict in software than in hardware? In a way current processors sort of JIT compile assembly to some hardware-native form, but if those hardware-level tools were accessible to software, software could do much much better optimizations and bugs could be patched.
The argument to expose this sort of control would be because domain knowledge would allow higher level domain knowledge to be used to tune the prefetching manually.
No. I'll list the reasons I know, but a real hardware designer will know even more.
There are many different ways to design hardware. The right thing to prefetch changes with different implementations. Unless you think everyone is going to ship source code?
Things like that already exist, e.g. for x86: https://c9x.me/x86/html/file_module_x86_id_252.html
> "...some form of parallelism (so that pipelines can be created with machine code and not just heuristics)..."
Not sure exactly what is meant by this. Either the answer is the hardware already automatically maximizes parallelization (https://en.wikipedia.org/wiki/Superscalar_processor) or the answer is that there's no way to physically rewire a chip on the fly.
> "...since it is probably easier and better to branch predict in software than in hardware..."
Been tried, doesn't seem to have been that successful IIRC. A cursory Google shows that x86 had (and dropped) branch hint prefixes for instructions and the Cell's SPUs had branch hint instructions as well. Various languages also allow exposing branch prediction hints to the compiler, e.g.: https://en.cppreference.com/w/cpp/language/attributes/likely
As an instruction set RISC-V is not significantly worse than ARM. RISC-V trade-offs performance to simplicity of implementation. I think this makes it good choice for embedded. IoT, security chips need to be cheap and simple. Price and size are more important than performance.
For example, stuff that lowRISC makes is never going to be high performance, but it can be very important for security point of view. https://www.lowrisc.org/our-work/
Well, yes, that's the whole point of having an open ISA. Users shouldn't be concerned at all, it's for computer engineers.
Binary compatibility matters on anything that isn't compiled specifically for the machine.
Yocto/Gentoo might have been better examples if you want to argue binary compatibility doesn't matter. Particularly if you need to compile the bootstrap image just to get the machine to boot.
That said, if you rebuild many apps with -march=native, -flto, etc there are frequently large performance benefits due to the compiler being able to selectively use things like AVX512/whatever for random code sequences where calling out to a library function, or checking for feature existence at runtime wipes out much of the perf advantage.
A large part of the advantage of a new architecture would be avoiding all this crap. If it comes baked in from the start that isn't a good start, considering what it will look like in a decade or two.
--
What's the boundary between microcode and a VM w/ JIT?
Some tidbits I've read, IIRC: Apple Silicon M1 does a surprisingly good job of running a x86 emulator. Some chips now use microcode to support novel ISA extensions. Some chips are adaptive, optimizing hot path ISA instructions. There were special purpose chips for LISP and JVM and probably others. Old school mainframes used to emulate other instruction sets.
Knowing a little bit about JVM, it's JIT, the Java Memory Model...
These (amazing) hardware advances kinda sound like a VM w/ JIT.
So at what point are these chips designed in conjunction with the JIT?
Isn't that kinda what Transmeta was trying to do?
--
What can these chips and systems do to improve security? Stuff like tagged data descriptors and buffer overflow protection.
The Burroughs processors had stuff like that. https://en.wikipedia.org/wiki/Burroughs_large_systems_descri...
Current OSs have a smattering of features. https://en.wikipedia.org/wiki/Executable_space_protection
Surely more could be done? So I assume someone somewhere is already doing it.
After all the speculative execution bugs I think it's pretty clear that Intel has reached a complexity threshold where it gets too difficult to reason about what the processor is actually doing. In that regard I think the "reduced" in RISC could enable us to write fast and safe programs. And we chuck out tons of legacy too, you can probably still run MS-DOS on the latest Intel chips.
I'm not too worried about fragmentation – just look at any two x64 CPU's and they won't support all the same features, this is an annoying but mostly solved problem. And AMD does pretty well, while every board essentially needs a custom bootloader and a unique description of where all the hardware is.
Fragmentation is in general horrible. It was a major problem with ARM32, and that was much more strictly defined with less variation. ARM64 tried to define things more rigidly and has mostly banished the problem. The ARM ecosystem continues to be held back though by fragmentation around bootstrapping, hardware enumeration, and other aspects of the system that surround the core. Every ARM board tends to be a special snowflake.
I can't imagine RISC-V beyond niche applications unless someone publishes a more strictly specified version of it that provides a unified platform.
They're working on this right now. Niche applications can still do their thing, but there will be standard profiles for e.g. a "Linux class" application processor, or an "ARM Cortex-M*" equivalent micro-controller.
Think of it like this: the difficulty of targeting RISC-V increases with the square of the number of variants.
It's a general rule in systems that difficulty and bugs increase exponentially, not linearly, as complexity increases.
Did a quick search on this, and I believe the Linux portion of this is the responsibility of the "UNIX-Class Platform Specification Task Group" [1]. They seem to be quite active, which I'm reading as a sign things are progressing.
RISC-V International is sometimes really bad at communicating that it's working on these problems. But odds on, they usually are.
Hardware enumeration IMO can be harder than dealing with ISA variations. (And to my knowledge, RISC-V hasn’t solved any hardware enumeration problems.)
What do you think `RV64GC` is?
RV64GCV, RV32IMAC, etc are all short-hand describing the supported capabilities of a given RISC-V CPU.
ARM has different specs for each type of core. https://en.wikipedia.org/wiki/ARM_Cortex-M
Compilers have handled this for years.
So if the CPU runs into an instruction that it doesn't understand, this will trigger a missing instruction trap and software can implement the instruction. Fragmentation problem solved, no?
The RISC-V ISA and some of the open cores allow (or even encourage) being bundled with proprietary hardware.
Even locked-down, user-hostile hardware with patents and cryptographic protections is allowed.
If you expect RISC-V to be the "Linux of hardware", think again. Your next phone will not be "free" as in "free-from-backdoors" or "free-from-patents".
Yet, compared to the status quo, it's a step in the right direction.
See, the confusing miasma surrounding USB and its various overloaded capabilities.
Or PCIe -- if you want to use ROCm on AMD GPUs, your PCIe complex needs to support "PCIe atomics", which, uh, none of my computers do. AMD's boards do, though!
That's nitpicking though. I don't think PC's open architecture is really comparable, the truly open bits like PCI are much less "open to interpretation" as RISC-V, while bits like the CPU socket, chipsets, and even the keyboard port were either proprietary or clones of proprietary tech.
Not anymore, at least for Vega cards: https://github.com/RadeonOpenCompute/ROCm/issues/800#issueco...
> AMD's boards do, though!
No board support is required, this is on the SoC ("CPU") side, unless you're trying to connect the GPU via a chipset-side low-bandwidth slot.
Intel supports it since Haswell on desktop (and earlier in Xeons apparently), Marvell ThunderX2 and Mellanox BlueField support it, I'm pretty sure Ampere does too.
In my case, I tried connecting both via thunderbolt on some skylake/coffeelake laptops and on power9. Neither Intel's TB3 controller nor power9 support the necessary extension.
Not really a big deal, but a nitpicky example of how "fragmentation" sometimes hurts.
Whereas the IBM PC was delivered as a complete system (including all the peripherals and glue logic) and to achieve 100% compatibility the clones were exactly that: they copied absolutely everything about the PC, down to level of the individual logic gates in the "glue" that interfaced the CPU and memory and peripheral controllers.
BSP junk is annoying, but you don't have to use it. Just buy hardware that works on mainline Linux. That might mean you have to buy last gen hardware, but so what? A quad core A53 is still fairly fast.
[1] https://gist.github.com/erincandescent/8a10eeeea1918ee4f9d99...
[2] https://lobste.rs/s/icegvf/will_risc_v_revolutionize_computi...
ARM64 (b/bl): These instructions reserve 26 bits of the 32 bit instruction for a branch target (with an implicit 2 bit shift since instructions are 4 byte aligned), resulting in the ability to directly jump ±128MB (AKA ±2^25 instructions).
RISCV (jal): This instruction reserves 20 bits off the 32 bit instruction for displacement (there is an implicit shit of 1 bit since all RISCV instructions are 2 byte aligned). This results in the ability to jump ±1MB (AKA ±2^19 instructions).
This is a often a non-issue for small embedded cores because the code running on them is fairly compact and can be tuned for specific cores. It is a nightmare for large desktop and UI stacks (or web browsers) which often have many linked images and are much larger than 2MB. You can make it all work, but you need to add extra address calculation instructions or branch islands to do it, and those waste a bunch of space (what arm64 can do in a single instruction requires 2 or 3 on RISCV). Now you have all those extra instructions in your I-cache, extra jumps to branch islands wasting predictor slots, etc. You can try to solve this in hardware by adding special predictors to recognize branch islands, or using do op fusion to recognize idiomatic jump calculations, but that makes the chips more complex and still does not solve the code density issue (you can try to overcome some of that with trace caches, but that is again more complexity).
There is no simple way to fix these issues in RISCV, because all prime encoding space is gone. The best you can do is add better addressing modes in the 48 bit opcode space, but that interoduces significant code bloat (if you just make every unresolved target in a .o file use 48 bit jump instructions), buys you very little (if you continue using 32 bit instructions by default and only use the newer instructions in linker generated branch islands), or requires complex software, binary format, and tooling changes that are never likely to happen in order to dynamically relax function bodies and have the linker choose the size of the instructions (and the real kicker is any improvements made to toolchains to accomplish this would still not overcome arm64's better instruction design BUT would provide some improvements to arm64 binaries).
I could go into a similiar analysis of pc relative load instructions and how adrp is much better than auipc for large codebases. RISCV just wastes tons of bits in prime places in the encoding space. JAL blows 5 bits on encoding a return register. Technically that is more generic and orthogonal than having an architecturally specified return register that the instruction uses implicitly, but those 5 bits are incredibly valuable, they would have increased the displacement from ±1MB to ±32MB. Yes, specifying the register lets them play fun tricks in their calling conventions to simplify their prologue and epilogue code, but that really cannot justify the loss of branch reach. What is so infuriating is that they had an instruction like that (J), but they removed it because they did not want any instructions to use implicit registers (and I believe it cannot be added back because the encoding space has been reused). I understand the desire for architectural purity, but by doing so they doomed every high performance implementation to micro-architectural chaos.
While it might be tempting to think I have just rabbit holed on a single issue, it really is a big deal. Something like 5-10% of generated instructions PC-relative jumps, so getting them wrong has significant impacts... I would estimate this one issue alone will result in a ~5-10% code size increase (but only once you start have large binaries, it does not have an impact for anything less than ~1-2MB in size). It might not matter for small embedded controllers or in order cores, but it makes implementing high performance out of order cores much more complex. It is certainly possible to overcome these issues, but it means that for out of order RISCV cores to achieve similiar performance to ARM64 cores on large codebases they will need larger more complex branch predictors, larger caches, and extra decode logic, and potentially trace caches. This is not an isolated issue, it is just one where I have domain expertise, I have heard similiar criticisms of other parts of the instruction set from people who work in other parts of the stack.
Just to be clear, I don't think RISCV is terrible. I think it will be great for people doing custom cores with custom toolchains to ship bespoke silicon in small devices where the general purpose compute requirements are low. IOW, it is great if you just need some sort of CPU core but that is not what is really special about your silicon. On the other hand, I simply do not see it ever being competitor to arm64 in high end mobile devices, desktops, workstations, or servers. In order to fix the issues with it they would need to reclaim a bunch of allocated instruction encodings (maybe RISC6)?
In other words, ARM's architects chose every parameter correctly, and RISC-V's chose every parameter badly.
It might be true, but you kind of have to prove it, not just assert it.
Take the J/JAL vs B/BL range for example. It's not just embedded. Look through your Linux distro's binaries and you'll find very few with TEXT size over 2 MB.
One of the few on my (x86_64, but it doesn't really matter) system is /opt/google/chrome/chrome with 159,885,517 bytes.
That exceeds ARM64's single-instruction BL range, as well as RISC-V's.
A quick analysis shows that of the 373500 callq instructions in the binary, statically 55.53% fall within the RISC-V single-instruction range, 100% fall within the ARM64 range. Dynamically I don't know, but I suspect the percentage that fall in the RISC-V range would be a lot higher.
Anyway .. code size. The extra AUIPC instructions needed in the RISC-V program will make it around 648 KB or 0.4% larger than the ARM64 program.
That's a pretty far cry from "I would estimate this one issue alone will result in a ~5-10% code size increase" you state. I mean -- that's a factor of 12x to 25x different than you state.
But wait there's more.
One reason that RISC-V JAL offsets are limited is that 2 bits out of 32 are taken up by indicating whether the current instruction is 4 bytes or 2 bytes in size.
So that's a waste right?
It would be if you didn't use it. But RISC-V does use it. In a typical RISC-V program, around 50% to 60% of all instructions use a 2 byte opcode, giving a 25% to 30% reduction in code size.
On the same 152 MB program (Chrome) where not having long JAL offsets costs 0.6 MB of code size, the C extension will probably save around 40 to 45 MB of code size.
That seems like a pretty good trade to me.
What will the speed effect of those extra AUIPC instructions be? I don't know. I'd have to instrument Chrome and run it at a fraction of normal speed to find out.
That's definitely something that should be done before making a pronouncement that one ISA is definitely better and the other one made all the wrong trade-offs.
However, my experience of analyzing smaller programs is that the dynamic penalty (execution speed) is typically much less than the static penalty (code size). At a wild guess, I'd go with four times less, or 0.1%.
That's in the noise.
Might a RISC-V core be enough simpler than a comparable ARM64 core to clock 0.1% faster? Could well be. Might it be enough simpler to be 0.1% smaller and thus cost 0.1% less in die space -- or allow you to put 0.1% more cores on the same chip? Could well be.
Even the detractors don't argue that RISC-V isn't simpler. "It's too simple" they say, takes purity and orthogonality too far.
Maybe, but you need to prove it, not just assert it.
I don't think the ARM architects did everything correctly and the RISC-V did everything wrong. I just chose an example I felt was an issue. On the other hand, I think that RISC-V supporting variable length instructions that are encoded with such that they can be easily decoded in parallel was very good use of encoding space. What frustrates me about RISC-V is that it feels like it ignored the last 20 years of industry experience and made a lot of unforced errors.
I think you are correct that I misestimated the branch density in normal linux binaries (the system I work on is a bit different), so I will take back my claim about code size increase, but I also think large binaries like Chrome are more significant than you seem to imply, especially once you start looking at desktop and mobile platforms. We can argue about people writing bloated code, but the fact is that apps like Twitter and Facebook ship mobile apps that are over a 100MB of executable code. And these things are not getting smaller over time. As code sizes increase that 2MB jump window is going to look very small.
It is going to be interesting to see how this plays out over the next few years.
> ISA fragmentation ... binary distributions harder.
A overly simply one-sided analysis. You have to look at the cost and the benefits. Not simply say 'look there is a cost' therefore it is bad.
The modular architecture also allows RISC-V to be optimal in many different industries and form factors, from literally the smallest CPU ever created to massive multi-core servers.
The system is designed so that as much software as possible can run on the minimal spec and thus work does not have to be repeated between different industries.
Just because people use the custom extension feature a lot with embedded, does not imply that the same thing happens for desktop/server. The constrains are different, the market is different, the industry is different. So far we have seen all linux distribution build on the same profile.
> Economics. RISC-V has actively courted embedded, which makes sense as a niche.
Actually wrong. The first profile that was standardized was the one for full linux.
Embedded simply got more interest because more people could get it to market faster, and many universities work on embedded.
This is open source, people are just gone use it for what they want, and embedded had the most need and the lowest barrier to entry.
> Openness doesn’t tickle down. The openness of an ISA doesn’t have much impact on the implementation. A design with restricted signing keys is completely acceptable under their licensing
The point of RISC-V to make it POSSIBLE to create an open chip and use it commercially.
People for many reasons wanted to use open implementations, and RISC-V makes this possible.
And thanks to this philosophy there are actually where nice open chips and open chips that have commercial appeal.
To say well not everything is open therefore its bad, is just such a wrongheaded attitudes, its unbelievable.
> Design flaws. RISC-V seems like it hasn’t learned anything from CPUs designed after 1991.
If you actually read the spec, the literally have design consideration for every instruction with all the learning from the past and why they did them. Simply because you don't agree with all their conclusions, doesn't mean they didn't learn anything.
And when drawing conclusions from only point out the issues with one side, without considering the others, you are just not doing serious analysis.
> To say well not everything is open therefore its bad, is just such a wrongheaded attitudes, its unbelievable.
No, the article merely says that the openness does not trickle down, and it is true and unfortunate.
Goal is to be just close enough to RISC-V to get benefit of work on it, but leave behind the design errors, so formal verification and compiler targeting can be ported with minimal effort. Credible lists of RISC-V design errors have been published.
In that area sometimes having easier design is much more worth then putting certain optimizations into the ISA spec.
But from what _I_ know RSIC-V is neither targeting nor suited for general purpose computing, like general purpose servers, desktops and any phone/tablet but low end ones.
The reasons for this are manifold, including manny thinks I can't assess and thinks like that for such targets you like want a bunch of changes. Like e.g. requiring support of one load between a LR/SC pair which might be required to be based on the LR.
But then if it would have targeted general purpose computing platforms I believe it would have failed.
The fact that RISC-V allows extremely simple implementations is what makes it successful I guess.
So they just need to bring out a tweaked RISC-V spec which requires more ISA extensions, more support for LR/SC and similar and maybe does also some ISA changes and voila we it can move into that space, likely reusing a good amount of tooling.
It won't take over user<->device centric computing (desktop/laptop/tablet/high end mobile). It might become the ubiquitious IoT processor, but the divergence of chip capabilities (and subsequent OS & ABI fragmentation) means nothing will be interoperable, even at source code level. When I compare that to the extreme interoperability of RPi + Pico Pi devices (even with all their painful flaws) I know which one I would prefer.
Really? RISC-V is pitched mostly against the likes of ARM, which seems to be doing fine without laptop/desktop/server class silicon.
Several RISC-V vendors are already shipping Cortex A53/A55 class CPUs, which are used as the LITTLE cores in mobile devices -- and even still the main cores in lower end mobile. Several RISC-V vendors have formally announced A72 (SiFive U84) or A73 (Alibaba C910) class cores. Alibaba is apparently using these internally already, and boards for general sale are expected this year. SiFive's U84 will probably be shipping in around 12 months from now.
ARM is a few steps ahead with A75 and A76, but those are just incremental developments and RISC-V is catching up fast.
It seems the article was written before the HiFive Unmatched was announced -- but I don't think it was written before the U74 CPU cores in the Unmatched were announced in October 2018, so I guess the author either wasn't paying attention, or else don't understand the standard 2 to 2.5 years from announcement of a core to shipping products using an SoC with that core. There is nothing surprising about the HiFive Unmatched.
Was the article also written before Apple announced its switch to ARM64 architecture and their M1 chip?
The M1 uses ARM's 64 bit instruction set, but is far ahead of anything from ARM or its other licencees in performance.
If someone made the same level of investment in a RISC-V core and SoC as in the M1 then that RISC-V product would perform basically the same as the M1. That's a several billion dollar investment. Apple has that kind of money, but the best known RISC-V vendors such as SiFive (total funding to date under $200 million) don't.
That's an economic problem to solve, not a problem with the RISC-V ISA.
Alibaba or Huawei might well make that kind of investment in RISC-V. They are definitely both very interested in it.
The article concludes with the same old links to uninformed people making uninformed criticisms of RISC-V. I don't know who erincandescent is other than having written this rather famous post. Apparent the credibility of the post lies in them being an ARM engineer. Could be. ARM has thousands of engineers.
Here's the opinion of probably THE most important ARM engineer of the 1990s and 2000s, Dave Jaggar who developed the ARM7TDMI, Thumb, Thumb2.
https://www.youtube.com/watch?v=_6sh097Dk5k
Check at 51:30 where he says "I would Google RISC-V and find out all about it. They've done a fine instruction set, a fine job [...] it's the state of the art now for 32-bit general purpose instruction sets. And it's got the 16-bit compressed stuff. So, yeah, learning about that, you're learning from the best."