4 ms·

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 p

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?

sharpneli 6y ago
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.
- scottlamb 6y ago
  > 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?
  - Someone 6y ago
    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.
    - scottlamb 6y ago
      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...
      - sharpneli 6y ago
        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.
    - Dylan16807 6y ago
      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.
pjc50 6y ago
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!)
- Hello71 6y ago
  > What happens when your preload of a byte that happens to be in a subsequent page trips a page fault? spectre

sharpneli 6y ago

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.

scottlamb 6y ago
> 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?
- Someone 6y ago
  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.
  - scottlamb 6y ago
    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...
    - sharpneli 6y ago
      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.
  - Dylan16807 6y ago
    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.

pjc50 6y ago

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!)

Hello71 6y ago
> What happens when your preload of a byte that happens to be in a subsequent page trips a page fault? spectre