Hacker News Reader

Comment by phire | Hacker News Reader

I'm not sure the gate count argument works in RISC-V's favour.

While RISC-V is quite optimised for gate count for small cores; In large wide OoO cores the variable length encoding really bulks out the decoders.

You basically have the same requirement as x86, where you have to attempt to decode a 32-bit instruction every 16-bits (because there is no alignment guarantee for 32-bit instructions), and then cancel out the invalid ones. It's not quite a bad as x86, you only need to look at two bits, but it still forms a long dependency chain, and probably requires at least one extra decode stage with complex routing to pick out all the valid instructions.

View on HN

You don't really have to have a separate decoder every 16-bits. What you have is a length decoder every 16 bits (so just a single nand gate over the first two bits versus a huge chunk of the prefix/opcode part of the decoder for x86), which then feeds into a set of muxes for the actual decoders. The actual increase in complexity ends up coming from the critical path of the stack up of length selection affecting start addresses (and therefore mux selections) for later instructions in the block, but even that's not nearly as bad as it sounds because you can use the same base trick behind a carry lookahead adder. When I did some experiments a while back, it ended up being less than half a pipeline stage overhead versus fixed width instructions kind of across the board.

So not nothing, but very far from a deal breaker even for wide 8, 10, or even 12 wide cores.

> you can use the same base trick behind a carry lookahead adder

YESSSS.

I've been pointing this out for years and years.

By the point that you're looking at the same propagation delay as a common 64 bit adder you're decoding 64 chunks of 16 bits per cycle. That's 128 bytes, or a 32-64 instructions wide decoder.

That is so much wider than anyone is making or contemplating — or that even makes sense given the size of basic blocks — that it's just a non-issue.

And even if you go to those extremes, the biggest nay sayer says the cost of the design flaw will require you to double the number of decoders, which hardly sounds like a big deal to me.

It's not even double, because half of them are RVC-only decoders.

The annoying thing about RVC is that 32-bit instructions can now appear misaligned. I would be far less annoyed about RVC if it didn't break alignment, as you could solve the problem with a bunch of RVC-only decoders at the misaligned offsets.

So you either need (almost) double the number of full decoders, or a length decode and a bunch of shifters to get each decoder the right input bits (which get larger the wider the front end is. The 8th instruction can be at one of 7 possible offsets)

Yes... but then you are kind of wasting a pipeline stage on nothing more than length decoding.

I suspect a design with a full decoder every 16-bits might actually win on everything but gate count, mostly because it can deal with variable length instructions and variable number of μops per instruction in the same step. A decoder that doesn't output a μop because it was clobbered by a previous instruction, can be handled the same was as a decoder that didn't output a μop because of μop fusion.

Actually, that approach might actually eliminate the need for the extra pipeline stage (just at the cost of gates).

It's certainly not a deal breaker. But it's a valid criticism of the ISA.

Ok, so you doubled the number of decoders, how is that not significantly better than x86?

I'm not even sure you have a point with regards to it being a valid criticism. Doubling the silicon area for instruction decoding probably costs nothing, because if you have a simple decompression stage, the maximum number of decoders is already doubled in the first place, because you're hypothetically encoding twice as many instructions to begin with. If you can double the decoders in the decompression stage, you can probably get rid of a separate decoding stage altogether and thereby reduce the cost to literally nothing.

Look, it might not be obvious but in university I once had to design an ASIP and then do the floor plan with Cadence and the area of the SRAM dwarfed everything to the point where my ASIP was a tiny vertical column in-between two SRAM chips. I personally was shocked by the fact that I struggled to even find my ASIP on the floor plan, because it was maybe ten standard cells wide in-between the SRAM blocks. Like, ridiculously tiny to the point where it is hard for me to even care about the area the ASIP took up.

I said easily less than half a pipeline not a full stage. Everything kind of shifts around a bit because of that, and it ends up being a pretty different design than a fixed width front end because of it (hence qualcomm's objections), but it's not clearly worse.

And for better than aarch64 density, it seems to make a lot of sense.

Nobody in high-performance does fixed-width instructions that allow lineary scaling parallel decoders. Arm basically requires certain instructions to be cracked into multiple uops before rename. That ends up analougus to decoding compressed instructions. RVC increases complexity before decode, how much that impacts things idk.

I don't believe this will impact performance in practice, because nothing forces CPU vendors to implement fast compressed instructions. If compressed instructions become slower than non compressed instructions as the instruction decoders get wider, compilers will stop emitting them in the future.

Reply on news.ycombinator.com