5 ms·

So basically this takes instructions like add %r1, %r2, %r3 along with their C code implementations and generates specialized 0-parameter instructions like

by traes 6y ago

So basically this takes instructions like add %r1, %r2, %r3 along with their C code implementations and generates specialized 0-parameter instructions like add%r1%r2%r3 This gets really hefty really fast. While many instructions can be eliminated (e.g., add%r1%r2%r3 == add%r2%r1%r3), the upper bound for an instructions set of m instructions (each taking 3 parameters) and n registers is mn^3. For an architecture with 50 instructions and 15 registers, that's 168750 instructions, which would require 18-bit opcodes. Interestingly, the optimal index-based implementation would use 6 bits per opcode and 4 bits per register, also for a total of 18 bits per instruction. Something I'm unsure about is how it handles literal parameters. Are unspecialized instructions left exposed in such a case? Do all literals have to be copied to registers? Even more instructions be introduced?

mcphage 6y ago
> For an architecture with 50 instructions and 15 registers, that's 168750 instructions, which would require 18-bit opcodes. Interestingly, the optimal index-based implementation would use 6 bits per opcode and 4 bits per register, also for a total of 18 bits per instruction. Wouldn't it have to be the same # of bits/instruction, since it's the exact same information?
- traes 6y ago
  Sometimes it can actually be more efficient, since more bits are wasted with indexing. Random example: 1234 opcodes, 12 registers. 1234 * 12^3 = 2132352 (22 bits) 1234 is 11 bits, 12 is 4 bits 11 + 3*4 = 23 bits so in this case, using indexes is less efficient by one bit per instruction.