Hacker News Reader

Comment by Someone | Hacker News Reader

I don’t think designing a fast CPU gets significantly easier with RISC-V. Yes, you don’t have to design an instruction set, but you still have to pick a good set of RISC-V of extensions, find the right mix of cache size, branch predictor memory size, number of integer and float ALUs, number of rename registers, vector size, etc, glue the parts together so that it all works and build something without hitting patents that others hold.

‘Cheaper’ only at come into view if you’re selling millions of devices, and even then there have been other designs that are similarly open for which you can’t buy really competitive cores.

View on HN

Reply to self: one thing that RISC-V will give you that your own custom ISA won’t give you is compilers. That can be a big advantage, as it makes porting OSes and applications much easier.

> I don’t think designing a fast CPU gets significantly easier with RISC-V.

Waterman, and probably his advisor Patterson, might disagree. The focus of the RISC-V design is avoiding aspects of legacy ISAs that make them harder to implement.

RISC-V has certainly managed to avoid obvious footguns like delay slots or register windows. OTOH there seems to be a lot of people who think RISC-V went too far down the "RISC purity" rabbit hole, and that relying on the C extension is not a good substitute e.g. for lack of more complex addressing modes. Those same people might instead suggest something like aarch64 as an example of a good general purpose ISA.

Secondly, for a high performance core, the consensus seems to be that the ISA mostly doesn't matter. The things that make a high performance core are mostly things that happen downstream of the instruction decoders. Heck, even the x86 ISA allows producing some pretty amazingly good cores. Conversely, for a simple in-order cheap core, the ISA matters much more.

x86 doesn't have any of the stuff that's hostile to high performance, it was perfectly positioned (to be clear, this was pure luck) to exploit the evolution of superscalar, out-of-order processors.

OTHER than the ridiculous instruction decoding, which is still today very slow for cold code on even the newest x86 cores.

Once you've decoded the crazy x86 instructions into µops in the µop cache then, yes, it avoided the worst CISC mistakes of multiple memory accesses (and potential page faults) in one instruction via having only one memory operand per instruction and not having indirect addressing.

It has a couple of them. Flag registers, global rounding modes, relatively small page size, strong memory ordering guarantees, complicated decoding (and I'm sure there are a few more). It's more that it was good enough and managed to sufficiently mitigate most of the problems pretty well.

I think x86 would have been long dead if it weren’t chosen for the IBM PC or if it weren’t married to Intel. The former guaranteed it customers, the latter superior manufacturing technology.

Reply on news.ycombinator.com