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.
Edit: nice work author, I love it!
Was there a wonderful telephone system and many interesting furry animals?
Avremu: An AVR Emulator Written in Pure LaTeX - https://news.ycombinator.com/item?id=13126595 - Dec 2016 (29 comments)
Show HN: Avremu – An 8-Bit Microcontroller in Pure LaTeX - https://news.ycombinator.com/item?id=8448322 - Oct 2014 (18 comments)
> You are writing an CPU emulator in TeX, the TYPESETTING system?
Yep.
> Are you insane?
Not that anybody knows of.
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.
That's quite funny.
It's... actually readable? For example https://gitlab.brokenpipe.de/stettberger/avremu/-/blob/maste... hits me as a very usual pattern to write emulators.
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.
