I guess this will be nice for industry, which may pass the savings along to the consumer, but as far as having auditable hardware that you have some control over, I don't see how this is any better than the ARM SoCs we already have--unless you're going to roll your own system on an FPGA.
That, and I'm kind of disappointed everyone has drunk the RISC kool-aid. I think a lot of RISC "performance" has more to do with compilers catering to the least common denominator than anything else. 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.
I was particularly impressed by Baker's old paper[0] on stack architectures in service of his Linear Lisp idea.
RISC-V benefits is mostly an open source license that is free of patents. I think the biggest reason for it is academic... there needs to be an open platform for academic research. I'm sure it is next to impossible for an average university to do that on ARM or x86 architecture.
> That, and I'm kind of disappointed everyone has drunk the RISC kool-aid.
Well, the thing is, RISC "won" the "RISC vs. CISC" wars, in the sense that more or less every ISA designed since has been RISC [1]. Of course, CISC also won in the sense that x86 is still around, and Intel is of course fabulously successful. So at least for high-end cores designed with a big budget, the extra decoder complexity doesn't appear to hurt that much. But if you're doing a new ISA from scratch, no need to repeat the mistakes of the past.
Now, one can always hope that something better comes around. I'm not particularly hopeful that stack machines would be it; Forth has been around for how many decades now, if it would be such a good idea I think it would have already made its breakthrough. But there's plenty of research-y stuff out there (I admit to not being very familiar with most of it). Such as asynchronous (clock-less) logic, non-binary (ternary) logic, Mill(?), reversible computing, dataflow architecture, neuromorphic computing, quantum computing, graph reduction machines, and whatnot.
[1] In the sense of
- Load-store architecture
- fixed-length instructions (yes, ARM thumb and RISC-V C slightly break this, but still)
- ISA designed primarily as a compiler target rather than for human ASM programmers.
RISC won fully. Intel decodes its CISC into an internal RISC (micro-ops) in the hardware. And despite years and years of optimizations, they can't reduce their power requirements to ARM levels.
To be fair, Intel's old x86 ISA is kind of a mess, so microcoding everything back down to an internal RISC may have been the only way for them to even keep the thing manageable.
As CISC goes, 680x0 seemed a little saner to me, and it had more registers so you didn't have to go to memory as much. Back when I did MIPS programming, I remember getting more of a boost out of having more registers to work with than I did from the shorter instruction cycles.
So the variables are all very entangled... is the edge due to RISC? register count? 40 years of cruft (in Intel's case)? better compiler support? something else? I just feel like the whole thing deserves a little more investigation...
Like you said ARM and x86, RISC and CISC, are the winners. I just wonder how much of that victory is due to circumstances of the time (like weak late-1980s compilers) and how much was due to clear technical superiority.
Well, if you're asking me, I'd say Intel is successful despite the technical shortcomings of the x86 ISA, not due to any technical advantages of it. Intel has the benefit of huge volumes (thanks to x86, yes), and they are very very good at chucking out big silicon wafers economically with low defect rates.
Thanks to those advantages, Intel can overcome the disadvantages of the ISA. Which aren't that big in their main markets, that is relatively high end cores.
That, and I'm kind of disappointed everyone has drunk the RISC kool-aid.
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.
> Plenty of low-end Chinese routers, phones, tablets, and various Android-running devices use MIPS
I don't think MIPS is common in phones or tablets anymore, those have moved on to the low end of ARM.
However, MIPS is still used in many networking devices and was up until recently, also used in set-top boxes (STB) like the kind you get from your cable provider.
> their performance (or once again, lack thereof) is notable
You don't need gobs of CPU performance in networking devices. All the layer 2 packet handling is done in hardware, and for layer 3 routing the MIPS core(s) are powerful enough to offer 100Mbit NAT performance, which is 99% of what home internet users need currently.
Most managed switches today are either using an updated version of the PowerPC 630 or some ancient and low clocked ARM core. [1]
You don't need gigahertz CPUs in these devices because the CPU is only there to run the management OS (typically Linux) which then configures the switching/routing hardware.
> One only has to look at the prominence (or lack thereof) of MIPS
There are billions of MIPS devices out there. Most homes will have one in their WiFi router, and others in their STB. The only reason MIPS isn't "prominent" is because the products aren't advertised as containing a MIPS core, and people don't know it's MIPS.
I'd figure at least from the perspective of the JVM and the CLR, you'd have less of an impedance mismatch on a stack machine. And with most compiled languages being conceptually very stack-y, I doubt it would hurt there either.
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.
Itanium had many things that needed sorting, and it would have taken one hell of a compiler to sort it all.
The RISC "victory" was called in the early 90s, and it was mostly benchmarked off of late 1980s compilers that were targeted to least-common-denominator register machines, so most fancy CISC instructions were never emitted, and stack architectures were barely even a consideration.
Even on RISC-to-RISC comparisons, having a compiler that caters to your specific ISA makes a huge difference. So, if it was a victory, I wouldn't call it a clear one.
I think anyone who tries to do a different architecture will have to put forward huge R+D themselves for proper code generation. Likely in the form of an LLVM backend, webasm JIT, maybe JVM, as well as on chip hardware techniques that at least fill the same role as OO execution.
I can't think of any hardware architecture that focused on super efficient execution and let the instruction generation chips fall where they may. Maybe the Cell in the PS3. Every other successful chip has seemed to try to deal with whatever instructions it is given as best it can.
That, and I'm kind of disappointed everyone has drunk the RISC kool-aid. I think a lot of RISC "performance" has more to do with compilers catering to the least common denominator than anything else. 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.
I was particularly impressed by Baker's old paper[0] on stack architectures in service of his Linear Lisp idea.
[0] http://home.pipeline.com/~hbaker1/ForthStack.html