Hacker News Reader

Comment by alain94040 | Hacker News Reader

To understand RISC, ignore the acronym it stands for, instead just think fixed-instruction, load-store architecture. That's what RISC really means today.

No variable-length instructions. No arithmetic instructions that can take memory operands, shift them, and update their address at the same time.

View on HN

Someone once explained it like “not a reduced set, but a set of reduced instructions”. Not r(is)c, but (ri)sc.

Pretty much what you say, I just liked the way of describing it.

It seems to me people are ignoring that the C stands for Complexity. What's reduced is Complexity of the instruction set, not the size of it (or even the instructions themselves). In the context of the coinage of the term, they almost certainly could have called it "microcode-free ISA", but it wouldn't have sounded as cool.

Doesn't the C stand for Computer?

Oops I'm wrong about the name but not about the spirit. This is the original paper: https://dl.acm.org/doi/pdf/10.1145/641914.641917

Is ARM even microcode free these days?

I dont think so

> No variable-length instructions

AESE / AESMC (AES Encode, AES Mix-columns) are an instruction pair in modern ARM chips in which the pair runs as a singular fused macro-op.

That is to say, a modern ARM chip will see "AESE / AESMC", and then fuse the two instructions and execute them simultaneously for performance reasons. Almost every "AESE" encode instruction must be followed up with AESMC (mix columns), so this leads to a significant performance increase for ARM AES instructions.

> think fixed-instruction, l[...]. That's what RISC really means today.

> No variable-length instructions.

So, ARM is not a RISC instruction set, because T32 (Thumb-2) instruction can be 2 or 4 bytes long.

Similarly, RISC-V has variable-length instructions for extensibility. See p. 8ff of https://github.com/riscv/riscv-isa-manual/releases/download/... (section "Expanded Instruction-Length Encoding").

What is with variable-length instruction aversion? Why is it better to load a 32-bit immediate with two 4-byte instructions (oh, and splitting it in 12/20 bit parts is non-intuitive because of sign extension, thanks RISC V authors) than with one 5-byte instuction?

Fixed width instructions allow trivial parallel instruction decoding.

With variable length instructions one must decode a previous one to figure out where the next one will start.

> With variable length instructions one must decode a previous one to figure out where the next one will start.

People said the same thing about text encodings. Then UTF-8 came along. Has anyone applied the same idea to instruction encoding?

That would eat precious bits in each instruction (one in each byte, if one only indicates ‘first’ or ‘last’ bytes of each instruction).

It probably is better to keep the “how long is this instruction” logic harder and ‘waste’ logic on the decoder.

That doesn't sound so bad to me, in comparison to fixed-size instructions. One bit in each byte gone to have the most common instructions take one byte instead of four. I can imagine that allowing much denser code overall.

Or it could be one bit out of every pair of bytes, to support 2-, 4-, and 6-byte instructions. I don't know much about ARM Thumb-2, except that it does 2- or 4-byte instructions, so clearly someone thought this much was a good idea.

Instruction encodings are below my usual abstraction layer; I'm just speculating...

That's still a bit of dependency between instructions, not much but it is there, and that does make making parallel decoder harder.

It's not all in favor of fixed width encoding though. Variable length has an advantage of fitting more things into the cache. So it's all a balancing act of ease of instruction decoding vs space used.

If you want to be able to decode a bunch of instructions in parallel you really want it to be simple.

You don't have to make it self-synchronizing like utf-8, but a prefix length encoding is a real asset.

All sorts of boundary issues occur when you're near the end of a page or cache line. How many instruction bytes should you load per cycle? What happens when your preload of a byte that happens to be in a subsequent page trips a page fault?

By comparison, 4byte instructions that are always aligned have none of those problems. Alignment is a significant simplification for the design.

(Somewhere I have a napkin plan for fully Huffman coded instructions, but then jumps are a serious problem as they're not longer byte aligned!)

> What happens when your preload of a byte that happens to be in a subsequent page trips a page fault?

spectre

...and even ARM breaks instructions into uops, just like x86.

Of course it does. The level of abstraction required for modern pipelining and OOo scheduling is still beneath ARM. I'm not that familiar with the details of arm on paper but it's not that low level by research standards.

Reply on news.ycombinator.com