Thus begins the slide from RISC to (what POWER/PowerPC ended up calling) FISC. It's not about reducing the instruction set, it's about designing a fast instruction set with easy-to-generate, generalizable instructions. Even more than PowerPC (which generally added interesting but less primitive register-to-register ops), this is going straight to richer memory-to-memory ops.
Begins? Where do SVE2's histogram instructions fit? Or even NEON's VLD3/VLD4, dating to armv7? (which can decode into over two dozen µops, depending on CPU)
RISC has been definitively dead since Dennard scaling ran out; complex instructions are nothing new for ARM.
>RISC has been definitively dead since Dennard scaling ran out
Except this is still not agreed upon on HN. Every single thread you did see more than half of the reply about RISC and RISC-V and how ARM v8 / POWER are no longer RISC hence RISC-V is going to win.
The RISC-V hype is crazy, but I feel like it must be a product of marketing. Or I'm missing something big. I've read the (unprivileged) instruction set spec and while it's a nice tidy ISA, it also feels like pretty much a textbook RISC with nothing to set it apart, no features to make it interesting in 2021. And it's not the first open ISA out there. Why is there so much hype surrounding it?
If anything, I got the vibe that they were more concerned about cost of implementation and "scaling it down" than about a future-looking, high-performance ISA. And I'd prefer an ISA designed for 2040s high end PCs rather than one for 2000s microcontrollers..
There's nothing exceptional in the spec because it's trying to insert itself into the industry as a standard baseline, so staying small and simple is pretty intentional.
Its whole deal is that you can design a 2040's ISA or whatever you want and run 2015 Linux on it.
Everyone is jumping on it because no longer do they have to deal with a GCC/LLVM backend, and a long tail of other platform support: they can focus on the hardware, and put their instructions on RISC-V (with some set of standard extensions).
The other thing, though less impactful on the industry adoption, is that the simplicity allows hardware implementations (aka "microarchitectures") to replicate intricate out-of-order designs that we're used to in high-performance x86 (and ARM) cores, with a small fraction of the resources (https://boom-core.org/).
The real question in the high-performance space is: who will be the first to get an OoO RISC-V core onto one of TSMC's current process nodes (N7, N5, etc.)?
> Everyone is jumping on it because no longer do they have to deal with a GCC/LLVM backend
That seems like why everyone in the low-end space would be jumping on it (like WD for their storage controllers). But that's not really an advantage over the existing ARM & X86 ISAs in the mid to high-end space since they already have that software tooling built up.
But that also seems rather narrowly scoped to those who are willing to design & fab custom SoCs, which seems to need both ultra-low margins and ultra-high volumes to justify. Anyone going off-the-shelf already has things like the Cortex-M with complete software tooling out of the box. And anyone going high-margin can always just take ARM's more advanced licenses to start with a better baseline & better existing software ecosystem (ex, graviton2, Apple Silicon, Nvidia's Denver, Carmel & Grace, etc..)
Yea I think most of the people hyping it here are just consumers and software developers with no plans to make custom cores. If anything, I imagine these people would rather have standard cores that work ootb rather than something customized. So I don't believe this aspect is a reasonable explanation for much of the hype.
I agree that ARM isn't going anywhere, as long as it can be licensed for less than it takes to design a good-enough RISC-V core, it will get used (with opensource designs slowly lowering the latter on average).
It's really more the small vendor ISAs that I expect to become rarer with time, not the existing ISAs to go away.
Frankly, RISC-V feels perhaps a decade too late, but so does LLVM, and alternate history is such a rabbit hole so I won't go into it (but I suspect e.g. Apple would've had a less obvious choice for the M1, if RISC-V had been around for twice as long).
> But that also seems rather narrowly scoped to those who are willing to design & fab custom SoCs
I'm expecting most of the (larger) adopters are already periodically (re)designing and fabbing their own hybrid compute + specialized functionality - like the WD example you mention (Nvidia replacing its Falcon management cores being another).
I don't know for sure, but I also suspect some of them also want to avoid having Arm Ltd. (or potentially soon, Nvidia) in the loop, even if they could arrange to get their custom extensions in there.
> I agree that ARM isn't going anywhere, as long as it can be licensed for less than it takes to design a good-enough RISC-V core, it will get used (with opensource designs slowly lowering the latter on average).
You don't have to design it yourself. The foundaries are working towards free hard cells of RISC-V cores in most of their PDKs. It's hard for ARM to compete with free.
Their SIMD vectorized instructions are very neat and clean up the horrible mess of x64 ISA (I am not familiar enough with Neon and SVE so I don't know if ARM is a mess too)
I Am Not A RISC Expert (IANARE), but I think it boils down to how reprogrammable each core is. My understanding is that each core has degrees of flexibility that can be used to easily hardware-accelerate workflows. As the other commenter mentioned, SIMD also works hand-in-hand with this technology to make a solid case for replacing x86 someday.
Here's a thought: the hype around ARM is crazy. In a decade or so, when x86 is being run out of datacenters en-masse, we're going to need to pick a new server-side architecture. ARM is utterly terrible at these kinds of workloads, at least in my experience (and I've owned a Raspberry Pi since Rev1). There's simply not enough gas in the ARM tank to get people where they're wanting it to go, whereas RISC-V has enough fundamental differences and advantages that it's just overtly better than it's contemporaries. The downside is that RISC-V is still in a heavy experimentation phase, and even the "physical" RISC-V boards that you can buy are really just glorified FPGAs running someone's virtual machine.
I think one less visible aspect of RISC is the more orthogonal instruction set.
Consider a CISC instruction set with all kinds of exceptional cases requiring specific registers. Humans writing assembler won't care much. When code was written in higher level languages and compilers did more advanced optimizations, instruction sets had to adapt to this style: A more regular instruction set, more registers, and simpler ways to use each register with each instruction. This was also part of the RISC movement.
* Temporary results belong in AX,so note in rows 9 and A how some common instructions have shorter encodings if you use AL/AX as a register.
* Counters belong in CX, so shift and rotation only work with CX. There is a specific JCXZ, jump if CX is zero, intended for loops.
* Memory is pointed at with BX,SI,DI, the mod r/m byte simply has no encoding for the other registers.
* There are instructions as XLAT or AAM that are almost impossible for a compiler to use.
* Multiplication and division have AX:DX as implicit register pair for one operand.
* Conditional jumps had a short range of +/- 128 bytes, jumping further required an unconditional jump.
Starting from the 80386 32 bit mode, a lot of this was cleaned up and made better accessible for compilers: EAX EBX ECX EDX ESI EDI were more or less interchangeable. Multiplication, shifting and memory access became possible with all these registers. Conditional jumps could reach the whole address space.
I heard people at the time describing the x86 instruction set as more RISC-like starting with the 80386.
I think this is specific to x86, which is not the only CISC CPU. Other CISC architectures are much more regular. I'm familiar with M68k which is both regular and CISC.
You then have others, like the PDP-10 and S370 which are also regular but doesn't have these register-specific requirements that the Intel CPU's are stuck with.
True, the 8086 instruction set is ugly as hell. The 68000 was much better. I never saw the PDP-10 or S370 assembly , so I can't comment there.
AFAIK it was a quick and dirty stopgap processor to drop in the 8080-shaped hole until they could finish the iapx432. Intel wanted 8080 code to be almost auto-translatable to 8086 code and give their customers a way out of the 8bit 64K world. So they designed instructions and a memory layout to make this possible, at the cost of orthogonality.
Then IBM hacked together the quick and dirty PC based on the quick and dirty processor, and somehow one of the worst possible designs became the industry standard.
Thinking of it, the 80386 might be Intel coming to terms with the fact that everyone was stuck with this ugly design, and making the best of it. See also the 80186, a CPU incompatible with the PC. Maybe a sign Intel didn't believed in the future of the PC ?
I think intel and IBM didn't expect the need for compatibility to be an issue. After all when the IBM PC was built generally speaking turning on and having a BASIC env was considered good enough. IBM added DOS so that CP/M customers would feel comfortable and it shows in PC-DOS 1.0. which is insanely bare bones. So it was not unreasonable for both IBM and Intel to assume that things like the PC-JR made sense, because backwards compatibility was the exception at that point not the rule. IBM in particular didn't take the PC market seriously and paid for it by getting their lunch eaten by the clones.
It's the clones we have to thank for the situation we're in today. If Compaq hadn't done a viable clone and survived the lawsuit we'd probably be using something else (Amiga?). But they did and the rest is history, computing on IBM-PC compatible hardware became affordable and despite better alternatives (sometimes near equal cost) the PC won out.
> See also the 80186, a CPU incompatible with the PC. Maybe a sign Intel didn't believed in the future of the PC ?
The 80186 was already well in its design phase when the PC was developed. And the PC wasn't even what Intel thought a personal computer should look like; they were pushing the multibus based systems hard at the time with their iSBC line.
No, although one could make that argument. RISC (reduced instruction set) has a few characteristics besides just the number of instructions -- most "working" instructions are register-to-register, with load/store instructions being the main memory-touching instructions; instructions are of a fixed size with a handful of simple encodings; instructions tend to be of low and similar latency. CISC starts at the other side -- memory-to-register and memory-to-register "working" instructions, variable length encodings, instructions of arbitrary latency, etc.
FISC ("fast instruction set") was a term used for POWER/PowerPC to describe a philosophy that started very much with the RISC world, but considered the actual number of instructions to /not/ be a priority. Instructions were freely added when one instruction would take the place of several others, allowing higher code density and performance while staying more-or-less in line with the "core" RISC principles.
None of the RISC principles are widely held by ARM today -- this thread is an example of non-trivial memory operations, Thumb adds many additional instruction encodings of variable length, load/store multiple already had pretty arbitrary latency (not to mention things like division)... but ARM still feels more RISC-like than CISC-like. In my mind, the fundamental reason for this is that ARM feels like it's intended to be the target of a compiler, not the target of a programmer writing assembly code. And, of the many ways we've described instruction sets, in my mind FISC is the best fit for this philosophy.
> RISC (reduced instruction set) has a few characteristics besides just the number of instructions
Many (or all?) of the RISC pioneers have claimed that RISC was never about keeping the number of instructions low, but about the complexity of those instructions (uniform encoding, register-to-register operations, etc, as you list).
"Not a `reduced instruction set' but a `set of reduced instructions'" was the phrase I recall.
Most of RISC falls out of the ability to assume the presence of dedicated I caches. Once you have a pseudo Harvard arch and your I fetches don't fight with your D fetches for bandwidth in inner loops, most of the benefit of microcode is gone, and a simpler ISA that looks like vertical microcode makes a lot more sense. Why have a single instruction that can crank away for hundreds of cycles computing a polynomial like VAX did if you can just write it yourself with the same perf?
Fair, haha. But I think the distinction intended lies in that the old CISC ISAs were complex out of a desire to provide the assembly programmer ergonomic creature comforts, backwards compatibility, etc. Today's instruction sets are designed for a world where the vast majority of machine code is generated by an optimizing compiler, not hand crafted through an assembler, and I think that was part of what the RISC revolution was about.
ARM already has several instructions that aren’t exactly RISC. ldp and stp can load/store two registers at a given address and also update the value of the address register.
Both x86, and 68xxx started that way. Old silicon actually game had a premium for smarter cores, which can do tricks like µOp fusions to compensate for smaller decoders.
RISC was originally about getting reasonably small cores, which can do what they are advertised, and nothing more, and µOp fusing was certainly outside of that scope.
Now, silicon is definitely cheaper, and both decoders, and other front-end smarts are completely microscopic in comparison to other parts of a modern SoC.
