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.
I had quite some fun implementing this at a very lovely lake in Sweden, while my colleagues were attending GPCE.
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
Edit: nice work author, I love it!
> rather than an ATtiny
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 had quite some fun implementing this at a very lovely lake in Sweden
Was there a wonderful telephone system and many interesting furry animals?
Related:
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)
I love whimsy.
> You are writing an CPU emulator in TeX, the TYPESETTING system?
Yep.
> Are you insane?
Not that anybody knows of.
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.
But that should be the way it is done rather than be a joke.
Next up: running LaTeX on an 8-Bit AVR, simulated inside LaTeX.
I guess postscript could be an other interesting target, so you could run your emulated C code on some printers.
Nifty. If you're going to really nail the side-project, go weird or go home. chef kiss
Now, let's get that 8bit microcontroller running Linux and run Linux inside a LaTeX document.
> Are you insane?
That's quite funny.
Had to read the title 3 times.
It's... actually readable? For example https://gitlab.brokenpipe.de/stettberger/avremu/-/blob/maste... hits me as a very usual pattern to write emulators.
I made an AVR emulator in Haxe/JavaScript.
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.
(Url changed from https://ctan.org/texarchive/macros/latex/contrib/avremu, which points to this.)