28 ms·

RISC-V isn’t as interesting as you think

121 points by glhaynes 6y ago

guerrilla 6y ago
I don't know anything about the design flaws, so I can't comment on that, but as for the rest, the strategy of RISC-V worked out pretty well for everyone with the advent of the PC[1]. I'm not sure why it wouldn't work again. What would be so different between how things were done then with the PC and this now? 1. https://en.wikipedia.org/wiki/Open_architecture https://en.wikipedia.org/wiki/Open_architecture
- spijdar 6y ago
  Well, it's not all peaches and roses. 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.
  - floatboth 6y ago
    > if you want to use ROCm on AMD GPUs, your PCIe complex needs to support "PCIe atomics" Not anymore, at least for Vega cards: https://github.com/RadeonOpenCompute/ROCm/issues/800#issuecomment-525925928 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.
    - spijdar 6y ago
      Yeah, it's the only reason I've thought about upgrading my polaris card up newer. 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.
- kiwidrew 6y ago
  RISC-V is just an instruction set specification. It says absolutely nothing about the peripherals that need to be attached to a RISC-V core to produce a usable system. 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.
  - guerrilla 6y ago
    That's not the point. The point is the open architectures of any sort are probably beneficial for everyone.
api 6y ago
The ISA fragmentation issue is the worst thing I've consistently heard about RISC-V. 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.
- bem94 6y ago
  > 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.
  - api 6y ago
    They need to be sure there are as few of these targets as possible. I'd suggest one 32-bit and one 64-bit, period. 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.
  - yoshuaw 6y ago
    That's really cool, I had no idea! 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. [1]: https://lists.riscv.org/g/tech-unixplatformspec https://lists.riscv.org/g/tech-unixplatformspec
    - bem94 6y ago
      Right you are, that's the group responsible. It's something of a priority for RISC-V international right now, because of exactly this worry. RISC-V International is sometimes really bad at communicating that it's working on these problems. But odds on, they usually are.
deleted 6y ago
[deleted]
ho_schi 6y ago
Who is CB? 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.
- tyingq 6y ago
  "Who is CB?" Calvin Buckley: https://cmpct.info/~calvin/ https://cmpct.info/~calvin/
  - ho_schi 6y ago
    Thank you!
pabs3 6y ago
Re ISA fragmentation: Linux has various well established mechanisms to deal with varying CPU capabilities, these are necessary and used on many other platforms.
hacknat 6y ago
I do think that RISC-V will open the door to open source implementations as well. It will take a long time, but we might reach a day when people are 3d printing their own chips. Why does everyone always put so much pressure on new technologies to change everything over night? Maybe RISC-V's best days are 10-20 years from now.
- tyingq 6y ago
  "we might reach a day when people are 3d printing there own chips" Hah! Imagining what die size a 40μm process might need to make a CPU. The Intel 8008 (1972) was 10μm.
  - Koshkin 6y ago
    I don't know why it would make sense, even (apart from having fun doing it). We do not print books at home even though we all have printers, we use print shops for that.
    - vidarh 6y ago
      We do not print books, but we do print plenty of photos and documents and newsletters that it'd take a professional photo lab or large-scale offset printers to print just a few decades ago.
      - oblio 6y ago
        The market for people home printing photos and documents and newsletter is probably 1 million times bigger than the one for people home printing CPUs, though.
        vidarh 6y ago
        Yes, and yet plenty of tools and products target that market anyway. Especially since while a good chunk of it is hobbyist use, another large chunk is small-run electronics where relatively high price tags can easily be justified. But even in the hobbyist space, while the people who would actually use the tools are few in numbers, many hobbyist projects get built in the 100's or even thousands - whether by end-users themselves or by people selling them to end users. FPGAs are often a good chunk of the cost of projects like that.
pabs3 6y ago
Re Economics: binary compatibility is not very relevant for folks using open source software, most of the time source code is pretty portable, Debian riscv64 seems to be above 98% built: https://buildd.debian.org/stats/ https://buildd.debian.org/stats/
- StillBored 6y ago
  What happens if your RISC-V implementation doesn't meet the debian requirements? Or for that matter, provides some sweet instructions that speed up memcpy, or whatever, 100x? 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.
  - pabs3 6y ago
    It just has to meet the standardised baseline that is already defined and all Linux distros use. For all the extensions, Linux has various well established mechanisms to detect and utilise varying CPU capabilities, these are necessary and used on many other platforms.
    - StillBored 6y ago
      As I'm sure your aware, those mechanisms aren't ideal. There are performance, maintenance and various other problems with them. They exist because distro's are compiled to the lowest acceptable common denominator and then libraries/etc are swapped in as needed. For something like x86, this is an acceptable tradeoff because there is an expectation that a distro boots on a 25 year old computer as well as the latest amd/intel offerings with a ton of new instructions. 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.
oytis 6y ago
> RISC-V’s openness is less at the benefit of the user and more for CPU vendors Well, yes, that's the whole point of having an open ISA. Users shouldn't be concerned at all, it's for computer engineers.
throwaway4good 6y ago
"Overall, RISC-V will lead in a revolution for nationalist vanity CPUs (think Loongson; no one will run them but for show and perhaps a niche of radical ideologues)." 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.
- tyingq 6y ago
  The use cases like what Western Digital is doing seems like a reasonable driver as well. If they demonstrate some notable cost savings versus ARM, that should drive other companies that direction.
  - rwmj 6y ago
    AllWinner are another one. They are currently doing 5 million RISC-V chips at TSMC, because that'll save them a few pennies per finished phone/tablet.
- MaxBarraclough 6y ago
  > 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.
  - quelsolaar 6y ago
    It was originally designed as an educational project to teach students simple CPU design.
    - MaxBarraclough 6y ago
      I don't think that's right, or if it is, Wikipedia [0] is giving a misleading account: > 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. [0] https://en.wikipedia.org/wiki/RISC-V#History https://en.wikipedia.org/wiki/RISC-V#History
MobiusHorizons 6y ago
The promise of RISC-V (as I see it) is that it allows for innovation in chip design with a relatively lower level of fragmentation than would otherwise be true. Without an open and extensible ISA companies would either have to afford the ARM architecture license, or build their own ISA, with all of the tooling and infrastructure cost that implies. This level of innovation implies some fragmentation, but by building on a common base, the pain of that fragmentation can be minimized.
seedless-sensat 6y ago
> RISC-V seems like it hasn’t learned anything from CPUs designed after 1991. 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 https://youtu.be/_6sh097Dk5k?t=51m10s.
- detritus 6y ago
  Thank you for this, and more specifically for adding the relevant timestamp - and more personally - for Jaggar's answer to the subsequent question regarding complexity in hardware and software stacks, which as a layperson is something I often think about. 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!
  - cat199 6y ago
    > 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. https://en.wikipedia.org/wiki/Lisp_machine https://en.wikipedia.org/wiki/Lisp_machine
  - Symmetry 6y ago
    Have you seen the Mill videos? Seems to have stalled out but it represents a lot of rethinking of assumptions. https://millcomputing.com/docs/ https://millcomputing.com/docs/
    - alien_ 6y ago
      I'm not a specialist in CPU design but to me RISC-V seems like an incremental evolution, nothing really ground-breaking, when compared to alternatives the main benefit is the openness/licensing/cost. But at the same time think that you can get a $5 raspberry pi and embedded ARM chips cost pennies. 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.
zokier 6y ago
When I hear RISCV hype, I can only think about ARM and the extremely sorry state of cross-compatibility there (see: Linux device tree and various vendor bsp junk), and how RISCV is just likely going to be same except worse. So, no I have no high hopes for RISCV.
- CameronNemo 6y ago
  Device trees are fine and what you would find deeper in an x86 system if you looked. 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.
audunw 6y ago
What he claims is design flaws is highly contested. It’s claimed that the flaws leads to lower code density, but this is simply false when you consider compressed instructions, which is supported by most implementations. RISC-V with compressed instructions is better than 64-bit ARM. The design of the compressed instructions is also much more elegant than ARMs Thumb instructions, which was reasonably dropped for 64-bit ARM
- vlovich123 6y ago
  Compressed instructions really hurt the parallelism of CPUs. See M1 for an example of what happens when you design your decoders to fetch independently of each other because the offset of their instruction is deterministic. I think a better model is for code to be compressed with an efficient encoder at cache line size (eg zstd with the dictionary defined to be your instruction set)
  - deleted 6y ago
    [deleted]
  - Veedrac 6y ago
    RISC-V compressed instructions shouldn't interfere with parallel decode at all. They're extremely simple.
    - vlovich123 6y ago
      I'm not talking about parallel decode. I'm talking about the fetchers feeding the decoders. How does the fetcher know where the instruction boundaries are if you have variable-length instructions? My understanding is that x86 is the worst here - while x86 gets broken down into RISC-like uops so the overall x86 hit isn't large, the fetcher is extremely complex & slow to try to get back some parallelism that x86 encoding loses. The compressed version of these instructions seems similarly complicated since the length of the instruction is dependent on the data operands to the instruction. 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.
quelsolaar 6y ago
RISC-V is great for platforms where low cost, simple design, existing toolchain is important. In these areas it probably is the future. 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.
- jayp1418 6y ago
  Risc-V + NetBSD + toaster :D
- beaner 6y ago
  > You dont want RISC-V in your PC Why not? Isn't the Apple M1 showing exactly the opposite?
  - mromanuk 6y ago
    Apple M1 is not RISC V, it’s Arm and it’s heavily tweaked
    - bem94 6y ago
      The point is that RISC-V allows people to build their own tweaked / extended processors without having to pay an ARM and a leg for it.
      - MangoCoffee 6y ago
        >without having to pay an ARM and a leg for it. why Apple M1 and AWS Graviton is based on ARM? if ARM license cost is a concern. even smaller players use ARM as well...
        mlyle 6y ago
        Because RISC-V wasn't ready yet, and still isn't ready. Ecosystems matter. But the ecosystem sure seems primed for massive growth, and there's no architectural reason why RISC-V can't perform as high as ARM and beyond.
jhallenworld 6y ago
RISC-V is a great soft-core for FPGAs. I no longer have to use vendor cores or SDKs for this.
- milesvp 6y ago
  This. Any article that doesn’t mention risc-v in the context of fpga design is missing the use cases that put it on my radar originally.
rwmj 6y ago
A lot of nonsense in this article, but I'll try to address his points: (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).
- Zigurd 6y ago
  Is there an effort to form a consensus around peripherals and driver support for the most widely used OSs?
  - rwmj 6y ago
    To some extent these kinds of things are discussed in the Unix platform spec WG: https://lists.riscv.org/g/tech-unixplatformspec https://lists.riscv.org/g/tech-unixplatformspec
- Nokinside 6y ago
  BOOMv is not high-end, even reasonably. 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.
  - PaulHoule 6y ago
    Right, every so often BOOM's Github page gets reposted as if it was something new, and some of the leadership of RISC-V will talk about this architectural feature or that architectural feature that might support a high performance RISC-V chip, but the proof of a high-performance chip is a high-performance chip. (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.)
nickik 6y ago
Its incredibly how dismissive people are, and clearly haven't thought about it that much. > 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.
- eeZah7Ux 6y ago
  >> Openness doesn’t tickle down. The openness of an ISA doesn’t have much impact on the implementation. > 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.
Nokinside 6y ago
I pretty much agree on all points except design flaws. 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/ https://www.lowrisc.org/our-work/
guerby 6y ago
I'm really surprised by those two lines blog posts that gloss over the complexity of ISA design and ecosystem and concludes riscv creator know nothing about nothing. 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.
- wmf 6y ago
  Plenty of people consider ARMv8 a better ISA than RISC-V; the addressing modes seem to be a real concern. Those same people mostly consider MIPS to be too simple for its own good; obviously this simplicity doesn't completely doom the architecture but there are some long-standing differences of opinion here.
  - brucehoult 6y ago
    There is plenty of evidence (rather than opinion) that with a decent compiler and hardware implementation the more complex addressing modes don't gain you anything worth the bother in either code size or performance. 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.
the_duke 6y ago
Can someone with domain expertise comment specifically on the criticisms regarding the mistakes in the core spec, like wasted 32bit space and missing important instructions, detailed in [1] and [2] ? [1] https://gist.github.com/erincandescent/8a10eeeea1918ee4f9d9982f7618ef68 https://gist.github.com/erincandescent/8a10eeeea1918ee4f9d99... [2] https://lobste.rs/s/icegvf/will_risc_v_revolutionize_computing#c_8wbb6t https://lobste.rs/s/icegvf/will_risc_v_revolutionize_computi...
- lgg 6y ago
  In my opinion those complaints are generally correct. I work on low level OS and toolchain components (static and dynamic linkers) and interact with CPU architects. When I looked at RISC V's addressing modes I was dumbstruck, they are completely inadequate for modern high performance desktop or mobile cores. Just compare the design of PC relative branches on the two architectures: 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)?
angry_octet 6y ago
RISC-V seems to be the equivalent of Go in so many ways, stylistic simplicity at the expense of performance and actual simplicity. That doesn't make it bad, just flawed like everything else. 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.
specialist 6y ago
Noob questions: -- 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_descriptors https://en.wikipedia.org/wiki/Burroughs_large_systems_descri... Current OSs have a smattering of features. https://en.wikipedia.org/wiki/Executable_space_protection https://en.wikipedia.org/wiki/Executable_space_protection Surely more could be done? So I assume someone somewhere is already doing it.
- pjmlp 6y ago
  Check CHERI architecture, it is also being supported by ARM and Microsoft. https://www.cl.cam.ac.uk/research/security/ctsrd/cheri/ https://www.cl.cam.ac.uk/research/security/ctsrd/cheri/
kaba0 6y ago
I don’t have much knowledge on the low-level intricacies of CPUs, could someone please answer a question of mine? There is an older, famous post titled something like “C is not a low-level language”, and relatedly one that assembly itself is not all that low-level today. 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.
- ori_b 6y ago
  Do you really want to write the code for this as a programmer?
  - kaba0 6y ago
    Not me, but a compiler backend would perhaps have better “materials” for optimization this way. There is no reason for existing higher level code to not be transformable to this “microcode”
    - ori_b 6y ago
      A compiler backend would have to do it statically, and would not be able to do it based on the workload that's being run. 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.
      - 6y ago
Ohwie6oaHem 6y ago
The main flaw in the emerging hardware ecosystem is the lack of reciprocal/cooperative licensing. 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.
dathinab 6y ago
RISC-V is targeting embedded customized chips and research and does quite well in that area. 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.
ncmncm 6y ago
Me, I'm ready for Risc6. Fewer CAPS, more value. 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.
j0057 6y ago
Thanks, but I myself will be the judge of what is interesting. 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.
brucehoult 6y ago
There's really a lot of severely misinformed opinion there. "Much of the hype of RISC-V is hoping for laptop/desktop/server class silicon." 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 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."

121 points by glhaynes 6y ago

I don't know anything about the design flaws, so I can't comment on that, but as for the rest, the strategy of RISC-V worked out pretty well for everyone with the advent of the PC[1]. I'm not sure why it wouldn't work again. What would be so different between how things were done then with the PC and this now? 1. https://en.wikipedia.org/wiki/Open_architecture https://en.wikipedia.org/wiki/Open_architecture

spijdar 6y ago
Well, it's not all peaches and roses. 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.
- floatboth 6y ago
  > if you want to use ROCm on AMD GPUs, your PCIe complex needs to support "PCIe atomics" Not anymore, at least for Vega cards: https://github.com/RadeonOpenCompute/ROCm/issues/800#issuecomment-525925928 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.
  - spijdar 6y ago
    Yeah, it's the only reason I've thought about upgrading my polaris card up newer. 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.
kiwidrew 6y ago
RISC-V is just an instruction set specification. It says absolutely nothing about the peripherals that need to be attached to a RISC-V core to produce a usable system. 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.
- guerrilla 6y ago
  That's not the point. The point is the open architectures of any sort are probably beneficial for everyone.

api 6y ago

The ISA fragmentation issue is the worst thing I've consistently heard about RISC-V. 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.

bem94 6y ago
> 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.
- api 6y ago
  They need to be sure there are as few of these targets as possible. I'd suggest one 32-bit and one 64-bit, period. 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.
- yoshuaw 6y ago
  That's really cool, I had no idea! 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. [1]: https://lists.riscv.org/g/tech-unixplatformspec https://lists.riscv.org/g/tech-unixplatformspec
  - bem94 6y ago
    Right you are, that's the group responsible. It's something of a priority for RISC-V international right now, because of exactly this worry. RISC-V International is sometimes really bad at communicating that it's working on these problems. But odds on, they usually are.

deleted 6y ago

[deleted]

ho_schi 6y ago

Who is CB? 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.

tyingq 6y ago
"Who is CB?" Calvin Buckley: https://cmpct.info/~calvin/ https://cmpct.info/~calvin/
- ho_schi 6y ago
  Thank you!

pabs3 6y ago

Re ISA fragmentation: Linux has various well established mechanisms to deal with varying CPU capabilities, these are necessary and used on many other platforms.

hacknat 6y ago

I do think that RISC-V will open the door to open source implementations as well. It will take a long time, but we might reach a day when people are 3d printing their own chips. Why does everyone always put so much pressure on new technologies to change everything over night? Maybe RISC-V's best days are 10-20 years from now.

tyingq 6y ago
"we might reach a day when people are 3d printing there own chips" Hah! Imagining what die size a 40μm process might need to make a CPU. The Intel 8008 (1972) was 10μm.
- Koshkin 6y ago
  I don't know why it would make sense, even (apart from having fun doing it). We do not print books at home even though we all have printers, we use print shops for that.
  - vidarh 6y ago
    We do not print books, but we do print plenty of photos and documents and newsletters that it'd take a professional photo lab or large-scale offset printers to print just a few decades ago.
    - oblio 6y ago
      The market for people home printing photos and documents and newsletter is probably 1 million times bigger than the one for people home printing CPUs, though.
      - vidarh 6y ago
        Yes, and yet plenty of tools and products target that market anyway. Especially since while a good chunk of it is hobbyist use, another large chunk is small-run electronics where relatively high price tags can easily be justified. But even in the hobbyist space, while the people who would actually use the tools are few in numbers, many hobbyist projects get built in the 100's or even thousands - whether by end-users themselves or by people selling them to end users. FPGAs are often a good chunk of the cost of projects like that.

pabs3 6y ago

Re Economics: binary compatibility is not very relevant for folks using open source software, most of the time source code is pretty portable, Debian riscv64 seems to be above 98% built: https://buildd.debian.org/stats/ https://buildd.debian.org/stats/

StillBored 6y ago
What happens if your RISC-V implementation doesn't meet the debian requirements? Or for that matter, provides some sweet instructions that speed up memcpy, or whatever, 100x? 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.
- pabs3 6y ago
  It just has to meet the standardised baseline that is already defined and all Linux distros use. For all the extensions, Linux has various well established mechanisms to detect and utilise varying CPU capabilities, these are necessary and used on many other platforms.
  - StillBored 6y ago
    As I'm sure your aware, those mechanisms aren't ideal. There are performance, maintenance and various other problems with them. They exist because distro's are compiled to the lowest acceptable common denominator and then libraries/etc are swapped in as needed. For something like x86, this is an acceptable tradeoff because there is an expectation that a distro boots on a 25 year old computer as well as the latest amd/intel offerings with a ton of new instructions. 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.

oytis 6y ago

> RISC-V’s openness is less at the benefit of the user and more for CPU vendors Well, yes, that's the whole point of having an open ISA. Users shouldn't be concerned at all, it's for computer engineers.

throwaway4good 6y ago

"Overall, RISC-V will lead in a revolution for nationalist vanity CPUs (think Loongson; no one will run them but for show and perhaps a niche of radical ideologues)." 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.

tyingq 6y ago
The use cases like what Western Digital is doing seems like a reasonable driver as well. If they demonstrate some notable cost savings versus ARM, that should drive other companies that direction.
- rwmj 6y ago
  AllWinner are another one. They are currently doing 5 million RISC-V chips at TSMC, because that'll save them a few pennies per finished phone/tablet.
MaxBarraclough 6y ago
> 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.
- quelsolaar 6y ago
  It was originally designed as an educational project to teach students simple CPU design.
  - MaxBarraclough 6y ago
    I don't think that's right, or if it is, Wikipedia [0] is giving a misleading account: > 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. [0] https://en.wikipedia.org/wiki/RISC-V#History https://en.wikipedia.org/wiki/RISC-V#History

MobiusHorizons 6y ago

The promise of RISC-V (as I see it) is that it allows for innovation in chip design with a relatively lower level of fragmentation than would otherwise be true. Without an open and extensible ISA companies would either have to afford the ARM architecture license, or build their own ISA, with all of the tooling and infrastructure cost that implies. This level of innovation implies some fragmentation, but by building on a common base, the pain of that fragmentation can be minimized.

seedless-sensat 6y ago

> RISC-V seems like it hasn’t learned anything from CPUs designed after 1991. 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 https://youtu.be/_6sh097Dk5k?t=51m10s.

detritus 6y ago
Thank you for this, and more specifically for adding the relevant timestamp - and more personally - for Jaggar's answer to the subsequent question regarding complexity in hardware and software stacks, which as a layperson is something I often think about. 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!
- cat199 6y ago
  > 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. https://en.wikipedia.org/wiki/Lisp_machine https://en.wikipedia.org/wiki/Lisp_machine
- Symmetry 6y ago
  Have you seen the Mill videos? Seems to have stalled out but it represents a lot of rethinking of assumptions. https://millcomputing.com/docs/ https://millcomputing.com/docs/
  - alien_ 6y ago
    I'm not a specialist in CPU design but to me RISC-V seems like an incremental evolution, nothing really ground-breaking, when compared to alternatives the main benefit is the openness/licensing/cost. But at the same time think that you can get a $5 raspberry pi and embedded ARM chips cost pennies. 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.

zokier 6y ago

When I hear RISCV hype, I can only think about ARM and the extremely sorry state of cross-compatibility there (see: Linux device tree and various vendor bsp junk), and how RISCV is just likely going to be same except worse. So, no I have no high hopes for RISCV.

CameronNemo 6y ago
Device trees are fine and what you would find deeper in an x86 system if you looked. 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.

audunw 6y ago

What he claims is design flaws is highly contested. It’s claimed that the flaws leads to lower code density, but this is simply false when you consider compressed instructions, which is supported by most implementations. RISC-V with compressed instructions is better than 64-bit ARM. The design of the compressed instructions is also much more elegant than ARMs Thumb instructions, which was reasonably dropped for 64-bit ARM

vlovich123 6y ago
Compressed instructions really hurt the parallelism of CPUs. See M1 for an example of what happens when you design your decoders to fetch independently of each other because the offset of their instruction is deterministic. I think a better model is for code to be compressed with an efficient encoder at cache line size (eg zstd with the dictionary defined to be your instruction set)
- deleted 6y ago
  [deleted]
- Veedrac 6y ago
  RISC-V compressed instructions shouldn't interfere with parallel decode at all. They're extremely simple.
  - vlovich123 6y ago
    I'm not talking about parallel decode. I'm talking about the fetchers feeding the decoders. How does the fetcher know where the instruction boundaries are if you have variable-length instructions? My understanding is that x86 is the worst here - while x86 gets broken down into RISC-like uops so the overall x86 hit isn't large, the fetcher is extremely complex & slow to try to get back some parallelism that x86 encoding loses. The compressed version of these instructions seems similarly complicated since the length of the instruction is dependent on the data operands to the instruction. 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.

quelsolaar 6y ago

RISC-V is great for platforms where low cost, simple design, existing toolchain is important. In these areas it probably is the future. 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.

jayp1418 6y ago
Risc-V + NetBSD + toaster :D
beaner 6y ago
> You dont want RISC-V in your PC Why not? Isn't the Apple M1 showing exactly the opposite?
- mromanuk 6y ago
  Apple M1 is not RISC V, it’s Arm and it’s heavily tweaked
  - bem94 6y ago
    The point is that RISC-V allows people to build their own tweaked / extended processors without having to pay an ARM and a leg for it.
    - MangoCoffee 6y ago
      >without having to pay an ARM and a leg for it. why Apple M1 and AWS Graviton is based on ARM? if ARM license cost is a concern. even smaller players use ARM as well...
      - mlyle 6y ago
        Because RISC-V wasn't ready yet, and still isn't ready. Ecosystems matter. But the ecosystem sure seems primed for massive growth, and there's no architectural reason why RISC-V can't perform as high as ARM and beyond.

jhallenworld 6y ago

RISC-V is a great soft-core for FPGAs. I no longer have to use vendor cores or SDKs for this.

milesvp 6y ago
This. Any article that doesn’t mention risc-v in the context of fpga design is missing the use cases that put it on my radar originally.

rwmj 6y ago

A lot of nonsense in this article, but I'll try to address his points: (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).

Zigurd 6y ago
Is there an effort to form a consensus around peripherals and driver support for the most widely used OSs?
- rwmj 6y ago
  To some extent these kinds of things are discussed in the Unix platform spec WG: https://lists.riscv.org/g/tech-unixplatformspec https://lists.riscv.org/g/tech-unixplatformspec
Nokinside 6y ago
BOOMv is not high-end, even reasonably. 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.
- PaulHoule 6y ago
  Right, every so often BOOM's Github page gets reposted as if it was something new, and some of the leadership of RISC-V will talk about this architectural feature or that architectural feature that might support a high performance RISC-V chip, but the proof of a high-performance chip is a high-performance chip. (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.)

nickik 6y ago

Its incredibly how dismissive people are, and clearly haven't thought about it that much. > 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.

eeZah7Ux 6y ago
>> Openness doesn’t tickle down. The openness of an ISA doesn’t have much impact on the implementation. > 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.

Nokinside 6y ago

I pretty much agree on all points except design flaws. 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/ https://www.lowrisc.org/our-work/

guerby 6y ago

I'm really surprised by those two lines blog posts that gloss over the complexity of ISA design and ecosystem and concludes riscv creator know nothing about nothing. 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.

wmf 6y ago
Plenty of people consider ARMv8 a better ISA than RISC-V; the addressing modes seem to be a real concern. Those same people mostly consider MIPS to be too simple for its own good; obviously this simplicity doesn't completely doom the architecture but there are some long-standing differences of opinion here.
- brucehoult 6y ago
  There is plenty of evidence (rather than opinion) that with a decent compiler and hardware implementation the more complex addressing modes don't gain you anything worth the bother in either code size or performance. 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.

the_duke 6y ago

Can someone with domain expertise comment specifically on the criticisms regarding the mistakes in the core spec, like wasted 32bit space and missing important instructions, detailed in [1] and [2] ? [1] https://gist.github.com/erincandescent/8a10eeeea1918ee4f9d9982f7618ef68 https://gist.github.com/erincandescent/8a10eeeea1918ee4f9d99... [2] https://lobste.rs/s/icegvf/will_risc_v_revolutionize_computing#c_8wbb6t https://lobste.rs/s/icegvf/will_risc_v_revolutionize_computi...

lgg 6y ago
In my opinion those complaints are generally correct. I work on low level OS and toolchain components (static and dynamic linkers) and interact with CPU architects. When I looked at RISC V's addressing modes I was dumbstruck, they are completely inadequate for modern high performance desktop or mobile cores. Just compare the design of PC relative branches on the two architectures: 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)?

angry_octet 6y ago

RISC-V seems to be the equivalent of Go in so many ways, stylistic simplicity at the expense of performance and actual simplicity. That doesn't make it bad, just flawed like everything else. 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.

specialist 6y ago

Noob questions: -- 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_descriptors https://en.wikipedia.org/wiki/Burroughs_large_systems_descri... Current OSs have a smattering of features. https://en.wikipedia.org/wiki/Executable_space_protection https://en.wikipedia.org/wiki/Executable_space_protection Surely more could be done? So I assume someone somewhere is already doing it.

pjmlp 6y ago
Check CHERI architecture, it is also being supported by ARM and Microsoft. https://www.cl.cam.ac.uk/research/security/ctsrd/cheri/ https://www.cl.cam.ac.uk/research/security/ctsrd/cheri/

kaba0 6y ago

I don’t have much knowledge on the low-level intricacies of CPUs, could someone please answer a question of mine? There is an older, famous post titled something like “C is not a low-level language”, and relatedly one that assembly itself is not all that low-level today. 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.

ori_b 6y ago
Do you really want to write the code for this as a programmer?
- kaba0 6y ago
  Not me, but a compiler backend would perhaps have better “materials” for optimization this way. There is no reason for existing higher level code to not be transformable to this “microcode”
  - ori_b 6y ago
    A compiler backend would have to do it statically, and would not be able to do it based on the workload that's being run. 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.
    - 6y ago

Ohwie6oaHem 6y ago

The main flaw in the emerging hardware ecosystem is the lack of reciprocal/cooperative licensing. 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.

dathinab 6y ago

RISC-V is targeting embedded customized chips and research and does quite well in that area. 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.

ncmncm 6y ago

Me, I'm ready for Risc6. Fewer CAPS, more value. 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.

j0057 6y ago

Thanks, but I myself will be the judge of what is interesting. 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.

brucehoult 6y ago

There's really a lot of severely misinformed opinion there. "Much of the hype of RISC-V is hoping for laptop/desktop/server class silicon." 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 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."