That's absolutely hilarious, and a pretty fun hack.
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.
The classic AVR instruction set does not include multiplication, you have to be targeting a device that supports AVRe+, such as an ATmega rather than an ATtiny. Try adding -mmcu=avr5 and it will show up pretty quick. Example: https://godbolt.org/z/x951M8fn8
The new ATtiny 0/1/2-series parts are full AVRxt cores with a few instructions removed due to lack of need for large memory access. The classic terminology differentiating product lines isn't particularly useful anymore. ATtiny can multiply now.
I've been thinking of perfecting my AVR-8 assembly by writing an AVR-8 emulator in AVR-8 assembly. This is less useless than it sounds because one could upload a small program into RAM and run it if you had such an emulator. AVR-8 has so many registers that it ought to be possible to dedicate only some of them to the emulator and let the rest be shared between the real and virtual environments,
The fact that you can do stuff like this with a typesetting system has always amused me. Back when I was in grad school for mechanical engineering, some other people in my research group were doing computational mechanics. We would always joke about writing all their simulations in TeX, so that the TeX file for their paper would include all of the simulation code too, and rebuilding the document would run all the simulations and generate the plots.
TeX is kind of an unfortunate accident in that respect: Knuth had explicitly set out to make a relatively underpowered macro processor, not a general-purpose programming language; yet at the end he couldn’t help realizing he had, in fact, built a Turing-complete language. (Some parts of appendix D of the TeXbook are much easier to comprehend if you know what continuation passing is.)
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.
reply