[fierarul]

I don't understand the hype for RISC-V at all. It's an instruction set that would... just require a new backend for clang/gcc/Java and mean nothing to me unless somebody makes something that just obliterates a Ryzen.

Why should developers care? We barely have a decent ARM ecosystem after years of ARM routers and Raspberry Pi. Now we are supposed to be enthusiastic we will do that yet again for RISC-V?

Is it because it's somehow more open? But ARM wasn't that closed afaik - lost of folks produced it.

And Sun Microsystems open sourced a 64 thread CPU, the OpenSparc and nothing happened.

So, in a nutshell, why?

[socialdemocrat]

The approach of making a small instruction-set with optional extensions means RISC-V is very well suited for making specialized co-processors. This story discuss that more in detail: https://erik-engheim.medium.com/apple-m1-foreshadows-risc-v-...

On example of this is Esperanto Technologies, which has created an SoC with slightly more transistors than the M1, which has over 1000 RISC-V cores which implement the RISC-V vector instruction set extension to allow the processing of a large number of matrices and vectors. Basically the ET-SoC-1 as they call it is supposed to offer superior performance in the Machine Learning domain. 30-50x better performance with 100x less power consumption.

Esperanto Technologies are using the full flexibility of RISC-V by having more general purpose RISC-V cores, four of them, which are meant to run an operating system, which schedules machine learning tasks to this large number of smaller vector oriented RISC-V cores.

My understanding is that creating a good ISA is actually quite a task. RISC-V has over 1000 contributors over years who have made it happen. Esperanto Technologies apparently began with their own proprietary ISA for their coprocessors but found they could not beat RISC-V, and that making something better would just cost a lot more money and resources.

So in short the value proposition is in having a highly customizable ISA, that is well designed. There are no such other options on the market. ARM isn't highly customizable, since it has over 1000 instructions you must implement. RISC-V only has 47 instruction you must implement. All fairly simple ones.

[sifar]

>> There are no such other options on the market. ARM isn't highly customizable, since it has over 1000 instructions you must implement. RISC-V only has 47 instruction you must implement. All fairly simple ones.

I think this is a wrong comparison. There is a subtle difference here that is being missed.

CPU's become bloated over time as they get used differently, as the applications shift, as they try to address newer areas. And with each iteration, they still have to support the legacy code. That is how you end up with thousands of instructions

It is easy to have a lesser instruction count when you are starting from scratch and have no legacy.

What is going to stop RISC-V from becoming another ARM or perhaps x86 even, in another couple of decades ? When it spans such a large application space that most of the extensions become default and the core becomes bloated ? Time for another ISA then.

[socialdemocrat]

No, because verification tools are made to verify that you don’t take an extension for granted. Compilers as far as I know are made to generate code for different extensions. The CPU also contains registers to check what extensions are present.

ARM is what it is because license holders are required to implement the whole ISA. RISC-V is kind of the opposite. You are required to assume extensions are optional.

And OS is supposed to trap instructions not implemented and jump to a software emulation of them.

I don’t know all the details. But the point is they are planning for this from the start and building their tools around this. That was never the case for ARM or x86. Hence it is premature to assume it will end up the same.

[imtringued]

It's time to talk about a completely different domain that makes programming be heaven. In electrical engineering there is no such thing as a generic component. There are only implementations of them and you have to pick among the company provided implementations. Imagine if you had to specifically choose a 4Ghz grade if statement in your programming language or make sure your while loop supports 1.3V on the CPU. You need to have a good mental model of how the statement are implemented to choose the right one.

That's how bad electrical engineering is. Programming is bliss in comparison. You can do the dumbest things and it still works out. Your computer will never go up in flames even in the most bug ridden C code base. RISC-V will bring this to a lesser extent to software development. There will be no "general" RISC-V CPU. Instead you have to constantly worry about whether your CPU supports these instructions. Implementing fallbacks will just cause very inconsistent performance drops among CPU manufacturers. Think of things like the Intel compiler disabling SIMD on AMD cpus except this time it's because the manufacturer didn't bother to implement a "bloated extension" where only one instruction is actually used but when it is used it's in Fortnite or some other popular game so you do extremely poorly in benchmarks.

[eeZah7Ux]

> You can do the dumbest things and it still works out. Your computer will never go up in flames even in the most bug ridden C code base.

...and that, unfortunately, explains the quality of a lot of software and the low entry bar for the industry.

[sifar]

The issue is not whether SW can work around optional extensions. The point is that if you want a general purpose performant cpu (like ARM/x86) targeting a wide swath of applications, you will end up with these optional extensions as default. And then it is as bloated as others. We are not talking about micro-architecture optimization here to make it more performant, but isa architecure.

Ofcourse, you can change the computing module to minimal base isa and specific accelerations in ISA/HW. But then you will be restricted to niche applications and never replace the incumbents for general purpose workload.

>> Hence it is premature to assume it will end up the same.

And it is wishful thinking that it will happen otherwise. Whether ARM/x86 thought about extension from the ground up doesn't matter if you are targeting the same application space as them.

I have not seen anything done to even acknowledge this issue, let alone do something about it, for the simple reason that this lies far into the future and has no impact on the current scenario.

Given time and legacy software, it will morph into one.

[socialdemocrat]

> The point is that if you want a general purpose performant cpu (like ARM/x86) targeting a wide swath of applications, you will end up with these optional extensions as default.

Yes, but the number of instructions is still minuscule compared to ARM and x86. It am sitting with the reference sheet here in my hand. It is just two pages. Very quick to read over.

> And then it is as bloated as others.

Eh... nope. A huge number of those instructions exist due to cruft building up over years, not due to an actual need. A major source the huge number of instructions is tons of SIMD instructions which have superseded each other. RISC-V designers have specifically sought to avoid this preferring a Vector extension instead which adds a lot fewer instructions as it is more flexible.

People keep saying that is complex, but several companies have already made implementations of this. Esperanto Technologies is making SoCs with over 1000 RISC-V cores with vector extensions. So it cannot be that complex if they can fit that many cores.

And the compiler technology is better developed for vector instructions than for SIMD.

> And it is wishful thinking that it will happen otherwise.

It is not wishful thinking to assume a couple of lessons have been learned decades later in ISA design. You can just read up on the details about how the RISC-V ISA has been designed to understand how they are able to keep things simple while still retaining flexibility.

> Whether ARM/x86 thought about extension from the ground up doesn't matter if you are targeting the same application space as them.

The flaw in your assumption is that you seem to think all those instructions are actually used and need to be able to handle modern tasks. Tell me how much software today needs special instructions for Binary encoded decimal numbers? x86 is full of that kind of legacy bloating the ISA, with no value to modern software.

> I have not seen anything done to even acknowledge this issue, let alone do something about it, for the simple reason that this lies far into the future and has no impact on the current scenario.

I think you should just read what they have said about all these things. They have thought a lot more about this than you seem to have. They been doing ISA design for many decades and seen problem develop over time. RISC-V is a response to all those problems of the past. To not build yet another bloated ISA with redundant legacy instructions.

[jmwilson]

ARM licenses and royalties are not free. The royalties are a small but significant cost of a chip (1-2%) and licenses on the IP are a large R&D cost for the designer.

China is obviously interested in RISC-V as their access to the US market is threatened, and they could be a driver of wider use.

[miohtama]

India is also focusing on RISC-V, as they do not have their own chip industry yet. Depending on the Western countries for your processors is something any country wants to de-risk.

[fierarul]

This seems relevant if my corporation wants to put some $M into producing a thing. But I paid like $200 for my CPU and I would love a $500 Ryzen. Either way, I don't really care if 1% goes to royalties -- my price fluctuates more than that just because of our national currency.

[jacob019]

You are not the target market. Maybe someday RISC-V will compete with desktop processors, but at the moment it is most interesting for embeded systems and coprocessors.

[fierarul]

Seems fair enough. Still, the hype is so big on HN it does seem like the hope is for RISC-V everywhere. It's like saying soon enough we will all program in Haskell.

[doctor_eval]

It seems unlikely that I’ll ever use a risc-v system in anger, but I’m interested in them anyway because at heart I’m a hacker, which to me means (in part) that I’m interested in technology.

Until recently, the technology world has been shrinking relative to the 90s. I cut my teeth on machines running z80, 6502 and 68k CPUs, and during my early career I developed and deployed on 88k (DG/UX), PA-RISC (HP/UX), SPARC (Solaris and DRS/NX), MIPS (Irix) and probably a bunch I forget. Things were even more diverse (but less accessible) in earlier decades - each system had its own OS, and sometimes more than one (I’ve used RSTS/E on PDP and CSM on System 25...).

Today, everything in the commercial world runs x86 and Linux. That’s it. Even Windows people are using WSL now. There are loads of reasons why that’s good, but the hacker in me finds it dead boring.

So when I see things like M1 or Raspberry Pi or ESP8266 or RISC-V, it reminds me of a time when there was a lot more diversity in computing, where I could wonder about how things worked and read about them and imagine what applications I might have for them. It’s exciting! It gets my hacker juices flowing. And this is hacker news, right?

So despite the chances of me ever using risc-v in anger being approximately zero, I still think the whole thing is fascinating, and I learned heaps about CPUs just from people comparing RV to ARM and x64.

I think that’s the reason the “hype” for RISC-V is “so big”. It’s not because it’s going to be everywhere, but because it’s quite literally hacker news.

[fierarul]

> I think that’s the reason the “hype” for RISC-V is “so big”. It’s not because it’s going to be everywhere, but because it’s quite literally hacker news.

:-)

Your whole post was a pleasure to read.

[0xTJ]

I think that's the wrong question to ask. Aside from those writing kernels, compilers, JITs, etc., developers don't need to care, that's the point of programming languages and compilers. Throw a toolchain at a developer and tell them to do it and they can do it.

Comparing RISC-V to OpenSPARC is comparing apples to oranges. One is an ISA, the other is a hardware project.

What do you mean by "We barely have a decent ARM ecosystem". Are you talking about the tools to build for those processors? Or the tools to build new ones of those processors? Or the actual chips that are available?

I'm basically always within 10m of at least a half dozen ARM processors, and a handful of 8051s. At worst, RISC-V could be equivalent to ARM, without many of the parts that suck about it.

[fierarul]

Are we talking about RISC-V as an abstract idea, the same way we would talk about the benefits of functional or object oriented programming here?

Or is the end goal to have hardware in stores that people can buy?

Wasn't SPARC a RISC architecture? (Wikipedia says so, but I'm no expert).

> What do you mean by "We barely have a decent ARM ecosystem". Are you talking about the tools to build for those processors? Or the tools to build new ones of those processors? Or the actual chips that are available?

I remember the early OpenWRT / RPi days when many packages weren't even compiling for ARM. Now I think we are in a much better shape. The chips were available, but the software ecosystem was way behind.

> At worst, RISC-V could be equivalent to ARM, without many of the parts that suck about it.

What I do know about ARM sucking is that the whole board design makes each product need a customer kernel more or less. Which is why we still don't have a "Linux for your phones". What I've read about RISC is that it's going to be roughly the same: encourage a lot of co-processors which mean custom boards to me and probably custom kernels.

[jabl]

> What I do know about ARM sucking is that the whole board design makes each product need a customer kernel more or less. Which is why we still don't have a "Linux for your phones". What I've read about RISC is that it's going to be roughly the same: encourage a lot of co-processors which mean custom boards to me and probably custom kernels.

FWIW, this has nothing to do with the ISA per se, and particularly absolutely nothing to do with whether the ISA is RISC, CISC, or something else.

The problem is that like so many other embedded systems, ARM systems don't have peripherals which are discoverable at boot, hence all that has to be hardcoded (or specified at boot via devicetree) into the kernel (e.g. the interrupt controller is model XYZZY and is accessible at address 0xBEEF). So you end up with a kernel binary that works only on a specific board.

The "server-class" ARM systems adhere to something called SBSA which is a specification incorporating things like UEFI, ACPI, PCIe etc. The end result being that SBSA systems can use a common distro kernel just like x86 systems can.

[fierarul]

I learned something, thank you! Considering how performant modern phones are I hope all adhere to SBSA or similar so I can install any OS on my phone just like I could on my 100Mhz PC way back.

[nickik]

Because you can't make an open ARM or x86 core. Yes SPARC was open before and not much happened from it, but just because something didn't work the first time, doesn't mean it not a good idea. The world is different now compared to then.

If we ever want to live in a world where we have open implementation that have a huge software ecosystem that is ready, we need an open well support ecosystem.

So, if you don't care about open source, then you don't care about RISC-V. If you do however, you probably should care.