3 ms·

Fixed width instructions allow trivial parallel instruction decoding. With variable length instructions one must decode a previous one to figure out where the

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.

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.