By the way, if I understood you correctly, this sentence

> I'm still missing 5 opcodes (MULS, MULSU, FMUL, FMULS, FMULSU), but until now I did not encounter a C file, the AVR-GCC emits these opcodes.

could be rewritten as

> There are 5 opcodes that are not implemented (MULS, MULSU, FMUL, FMULS, FMULSU), as I have not yet encountered a C file for which AVR-GCC emits these opcodes.

Was there a wonderful telephone system and many interesting furry animals?

When he did set out to build a programming language, Knuth built METAFONT, and it’s just ridiculous how much nicer that is to program—even though it shares with TeX its token-stream-transformer nature and the standard pitfalls of grammarless macroexpanders such as miserable syntax error messages.

It turned out to be more awkward than I expected. Most 8-bit processors have instructions fairly clearly specified in the first byte. So the bulk of the decoding work can be done with a small jump table. The avr is more bit packed. Due to the way I progressively implemented the instructions I ended up with a kind-of tree of case statements. At some stage I'd like to go back and have a converter to a larger but easier to decode format. Instructions being in ROM(ish) and being easy to detect when updated means AOT is easy enough to do.

It might only need 32 bits per instruction. Opcode in the first byte and then byte aligned operands.