Hacker News Reader

Comment by phkahler | Hacker News Reader

As someone who has followed tech for almost 40 years, I've watched a lot of things come and go. I've seen "the next big thing" go nowhere countless times while some obscure things surprised me. Well intentioned good ideas didn't make it because of external factors or they lacked enough momentum to push through developmental barriers. Having seen all of that, my assessment of RISC V is simple: If they complete the privileged spec as planned this year (and hopefully the vector extensions too) it's going to explode onto the stage like newly formed star. The ramp will appear slow to people with high hopes and unrealistic expectations, but in the context of my life it will be a sudden shift the likes of which are rarely seen.

That is IFF they get the specs finalized, and I hope they support Googles VM threads while they're at it.

View on HN

I'm not sure about that. What matters most is the ecosystem. That's why people pay for x86 and ARM. The ecosystem that RISC-V offers will need to be at least as good or good enough for whatever users. They'll also have to be successful with lower volume despite high costs of ASIC development. Finally, remember that OpenSPARC was around for a long time with open-source implementations like Leon3 that mostly went nowhere outside established companies already using them.

I'm not so optimistic. I wish the best for them but precedents go against it.

OpenSPARC suffers from the same problem as most of the other alternate chips: I cannot buy a motherboard for a PC case and start going. Dev boards are cool but $1,000 motherboards[1] is not going to fly. When these alternate architectures get to the point I can buy a motherboard at a $500 or below price, I'll believe they are golden.

I really want it to succeed, but PowerPC and POWER have left their scars.

1) Talos™ Mainboard for $3,700 for a POWER 8

The reason those boards you buy are cheap is theres a boatload of people who pay for them. Need quite a bit of volume to get a custom, high-performance ASIC and board down to a few hundred. The problem is on the demand side. The suppliers would have to come up with millions of dollars for development and advertising then risk losing most of it. Most that do go bankrupt or get acquired after they fail (esp in FPGA or accelerator space).

The thing that has delayed Linux on RISC-V is simple enough: They keep changing and breaking ABIs. There was even one massive source break (changing #ifdef __riscv64 to __riscv) which broke several projects that I'd contributed RISC-V support to.

The reason that the Fedora port is on hold is because I'm waiting for everything to go upstream so that this sort of thing stops happening.

IMO this was entirely avoidable, and would have meant that we could have had both Fedora and Debian full RISC-V ports one or two years ago.

The way I understand it, those breakages happened because problems were found during porting. So it is kind of an egg-hen problem. Without porting problems cannot get fixed and in a stable state. Without a stable state people do not want to port things.

They could have maintained backwards compatibility (eg. by still defining #define __riscv64 as a deprecated definition), but chose not to. More of a problem is there was no real process for making the changes or informing anyone about the changes, they "just happened" and we only noticed later.

Anyway, once glibc & kernel changes are upstream, we'll have the stable ABIs we need. I'm very much hoping that upstreaming will be completed this year.

>> The reason that the Fedora port is on hold is because I'm waiting for everything to go upstream so that this sort of thing stops happening.

Fortunately that is happening. GCC 7 now has RISC V support and will be the compiler for Fedora 26. They really do need to get the priv spec finalized so kernel patches can go upstream as well. It's falling into place slower than people (both of us included) would like, but it is happening much more so than it did for Power, Sparc, or OpenRisc.

> I hope they support Googles VM threads while they're at it.

I saw the slides on the VM threads concept. I'm unsure as to the point. A process essentially sees a virtual CPU, multiplexed by a kernel. The point of a hypervisor could be understood as multiplexing things (aka OSes) that weren't written to share hardware.

What exactly is the point of a VM thread, which I understand as something which makes a VM look to a kernel as a process?

There doesn't seem to be any "win". Apart from perhaps making implementing Type II hypervisors, like KVM, easier. My critique of them is that their TCB is far larger than the Type I kind.

And all this for an architecture that doesn't have any legacy binary software... very strange.

I only say that not because I'm convinced at all about the concept, but because it seems interesting enough to ensure that it's not excluded. I'd like them to be able to run with it a bit and show us more evidence of the advantages. OTOH if supporting it is a bigger deal than I thought then no.

> If they complete the privileged spec as planned this year (and hopefully the vector extensions too) it's going to explode onto the stage like newly formed star.

Why do you think that? In which market? Who's going to pay to market it to SoC vendors and provide the very necessary pre-sales work? You aren't expecting it to put a dent in Intel, are you?

Which market gets it first is not something I can predict. The ground swell is deep and wide though. It's being designed in to products where the architecture will not matter to the consumer. nVidia is very interested and contributing - I would not be surprised if they made something like Tegra with RISC V in a year or two. The government of India is funding several designs (because they want their own processor IP), as are students around the world. Some of the vector implementations are power and area efficient enough that they compete with the best. Don't be surprised if it shows up in the Top 500 in the next few years.

On the software side you've got GCC, LLVM, core boot, Rust, and Google Go, all going there. There are thousands of Fedora and Debian packages already ported.

Several companies exist to support real world implementation by others - they'll help you put RISC V into whatever SoC or system you want.

This is all falling into place for an instruction set that has no production silicon yet. It's going to go somewhere. All it needs is finalized specs and some actual hardware.

Having said all that, one thing desperately missing is a free GPU. If SoCs for the public do arrive soon they will have to come from someone with graphics IP.

I don't expect Intel to be directly affected for a good while, but they will be missing out on whatever markets it takes for the next few years. I do see ARM in grave danger, but not immediately.

As for GPU, there is Nyuzi - http://nyuzi.org/ which is supported by lowRISC. They even proposed GSoC project for it

> one thing desperately missing is a free GPU.

I wonder if the Larrabee approach would work here: many simple RISC-V cores running in parallel, with wide vector units and a little specialized hardware (eg texture sampling).

I've thought about that. Just 8 or 16 cores running LLVMpipe should be able to do quite a bit of basic graphics. Certainly enough for a RaspberryPi type SoC.

> instruction set that has no production silicon yet.

There's no shortage of those ..

> It's going to go somewhere

.. why? Could you expand on the "step 2: ???" of the world domination plan?

For 32bit micro controllers, you can buy the highfive1 today.

Some companies are designing RISC V into their products (nVidia, Samsung) but not for user facing applications yet. There are designs in process to bring about something like the raspberry pi, which will bring it to the masses (not the consumer masses). There is a ton of corporate and academic support behind the effort.

But let me offer simple slightly plausible scenarios: What if Google ported Android to it? What if Apple brought iOS to it? What if some other new thing that takes off is based on it?

What if my grandmother had wheels? Then she'd be a wagon.

> What if Google ported Android to it?

OK. So .. what advantages does this offer? Why would they do that? Why would manufacturers choose the unknown option?

> What if Apple brought iOS to it?

Why would they do that? What advantages does it offer?

I'm just asking for the really basic features/advantages/benefits stuff. Preferably including an explanation of why said advantages can't be cloned or overtaken by Intel or ARM.

I think it's low probability, but look at what Google has done in the past. They bought/created Android and made it free or low cost to get onto phones. They bought On2 to make codecs free - they give away hardware designs for VP8 and VP9. It would be right in line with that to port the OS to a free ISA so hardware makers could lower their costs by whatever that ARM license is costing them and reducing power (increased battery life). It just feels like something they might do.

Having said that, RISC V doesn't need something like that to happen. It's going places already because it's better in a number of ways.

Here, watch this: https://www.phoronix.com/scan.php?page=news_item&px=NVIDIA-R...

And notice that they indicate a desire to run a full OS and apps in the future. Tell me that doesn't seem like a step toward Tegra with RISC V.

And then there is Samsung aiming at IoT with it. And others...

Isn't risc/mips the only cpu that has a chance of being fully open sourced now? There is Power as well, but IBM has a funny way of "open sourcing" things.

The patents on the older ARM processors have expired in the past few years, so there are open implementations of the first few generations of architecture. AMBER [1] is one such project.

http://opencores.org/project,amber

Reply on news.ycombinator.com