Western Digital Plans to Ship More Than One Billion RISC-V Cores a Year

Samsung is developing their own RISC-V cores too...

Agree completely. One only has to look at the prominence (or lack thereof) of MIPS, the other "pure RISC" architecture, to see that it's not known for being anything other than cheap. Plenty of low-end Chinese routers, phones, tablets, and various Android-running devices use MIPS; and their performance (or once again, lack thereof) is notable. ARMs are, internally, much closer to x86 than MIPS or RISC-V.

That said, there's always a place for cheaper and simpler 32-bit cores in applications like HDD controllers, where high performance and efficiency is not a primary goal.

If you had a language/compiler that took better advantage of a stack architecture, or even a CISC architecture, the performance would probably be just as good if not better.

Stack architectures are pretty easy to generate code for and have a (slight) advantage with code density, but their memory access patterns are hard to optimise for, and they are even harder to make superscalar.

On the other hand, I think a "CISC-V" could become an interesting and possibly quite competitive alternative to x86.

I do have a question, though. Is there any plan for working on an architecture for massively parallelizable workloads, like graphics, artifical neural networks and simulations? Especially the talk by Dave Ditzel seems relevant to this. Even without competitive performance, that would be another major step. It would not only improve the situation by the amount of the necessary efforts for that, but by raising the bar for all the other vendors by being compared to that.

There is a factor between your work and the impact on the ecosystem, and I guess it is significantly higher than one.

That, and you could save on instruction bandwidth since the operands could be implicit stack offsets instead of having to be specified in the instruction. (I believe Moore's GreenArray chips packed four instructions to the word.)

It might be a dead-end, or there could be some serious potential that is just being overlooked. Everyone is so accustomed to register machines (CISC or RISC) these days that it may be a while before the idea is reevaluated.

edit: Sorry! Just read this back, and realized I just repeated what you wrote in different words.

As far as binary compability is concerned this is more or less a thing of the past. The way I see it js and other interpreted languages provide for the most vibrant ecosystem at the moment. Where we have package management running not over only kernels but also distributions.

Before this developers have gotten really acustomed to compiling into platform independent bytecode. And even windows which in comparison with Linux has been ported to few platforms is by no means impossible to move over to a new instruction set. As have been demonstrated multiple times. Even C itself was developed to make few assumptions in regards to the metal. If you please, excuse me for reiterating facts well known to the average HN reader.

Furthermore with developers more or less requiring to work with open source software as it makes debugging and making use of other developers experiences easier. The probability that you will be stuck with CPU specific binaries of any given program is slim.

Now the problem is "only" to find programmers capable of programming 4096 CPU cores to operate well simultaneously, in a world where it's completely accepted and right, for a text editor to eat up hundreds of megabytes of ram displaying the source code for a hello world program. Also for this to truly make a dent the development has to span all the way from the metal via the kernel and to the actual application.

Unfortunately I am afraid that the open license will mean very little, from a freedom point of view as they take this route out of the pragmatic reasons, briefly mentioned above, not to make an ideological stand. Nonetheless it's a step forward so I'll try to supress my cynicism.