> While I'm not a hardware designer, my gut says that you can probably do x86 instruction length-decoding in one cycle

That's some very faint praise there. Especially when you're trying to chop up several instructions every cycle. Meanwhile RISC-V is "count leading 1s. 0-1:16bit 2-4:32bit 5:48bit 6:64bit"

▲

mohinder 3 days ago | parent [-]

The chopping up can happen the next cycle, in parallel across all the instructions in the cache line(s) that were fetched, and it can be pipelined so there's no loss in throughput. Since x86 instructions can be as small as one byte, in principle the throughput-per-cache-line can be higher on x86 than on RISC-V (e.g. a single 32-byte x86 cache line could have up to 32 instructions where the original RISC-V ISA might only have 8). And in any case, there are RISC-V extensions that allow variable-length instructions now, so they have to deal with the problem too.

	▲	codedokode 3 days ago \| parent \| next [-]
		As for program size, I played with small algorithms (like binary search) on godbolt, and my x86 programs had similar size to RISC-V with compressed instructions. I rarely saw 1-byte instructions, there almost always was at least one prefix. > e.g. a single 32-byte x86 cache line could have up to 32 instructions where the original RISC-V ISA might only have 8 With compressed instructions the theoretical maximum is 16. > so they have to deal with the problem too. Luckily you can determine the length from first bits of an instruction, and you can have either 2 bytes left from previous line, or 0.
	▲	Dylan16807 3 days ago \| parent \| prev [-]
		> The chopping up can happen the next cycle It still causes issues. > Since x86 instructions can be as small as one byte, in principle the throughput-per-cache-line can be higher on x86 than on RISC-V (e.g. a single 32-byte x86 cache line could have up to 32 instructions where the original RISC-V ISA might only have 8). RISC-V has better code density. The handful of one byte instructions don't make up for other longer instructions. > And in any case, there are RISC-V extensions that allow variable-length instructions now, so they have to deal with the problem too. Now? Have to deal with the problem too? It feels like you didn't read my previous post. I was explaining how it's much much simpler to decode length. And the variable length has been there since the original version.