Hacker News Reader

Comment by fastaguy88 | Hacker News Reader

I am curious. As I understand it, both RISC and CISC processors are implemented in microcode for the actual hardware gates on the chip. And perhaps different hardware generations make it easier to build different micro-code machine architectures.

So why not just offer an instruction set that matches the base hardware architecture? Rather than have all that decoding done on the chip, why not by a compiler? I understand that branch prediction can only be done at run time, but presumably there is some "closer to the metal" instruction set that would be faster than instruction decoding. Or is instruction decoding very low cost?

View on HN

> So why not just offer an instruction set that matches the base hardware architecture?

That's pretty much what a VLIW is. The problem is, well, it matches the base hardware architecture. Any change at all in μarch means a full rewrite of any binary code you might ever want to run on the chip. The Mill folks (who are essentially doing a VLIW with lots of clever heuristics/tricks to try and extract more parallelism from the code, on par with mainstream out-of-order chips) are unusually clear about that. Part of the point of a generic ISA like RISC-V is to act as a layer of abstraction, and the "close to the metal" approach you're describing doesn't do that.

To answer the last question first: Yes instruction decoding is dirt cheap (generally speaking) the thing that slows down a CPU is memory model, register retirement etc.

In theory RISC was intended to be basically no microcode where the CPU would expose the hardware instructions. In reality that is done to an extent but superscalar basically made the advantage that had mostly obsolete. This left RISC having the main advantage of having a ton of registers which does simplify other things when designing a superscalar CPU. But at the end of the day most architectures are falling into the "FISC" singularity where speed is all that matters. This is why AARCH64 was deliberately designed to be insanely superscalar from the ground up.

I think that comparability is usually pretty important. You want want a cpu that your existing compiled programs will run on. Also compiler support, if every new revision required a new instruction set then all the compilers out here would need updating each time. I believe instruction decoding is pretty damn fast (and pipelined too!)

It turns out sufficiently advanced compilers are hard to write (see: Itanium)

Reply on news.ycombinator.com