Avremu: An AVR Emulator Written in Pure LaTeX | Hacker News Reader

Avremu: An AVR Emulator Written in Pure LaTeX

gitlab.brokenpipe.de

124 pointsdcschelt29 comments

This is awesome, great job! How long before we can write ShareLaTeX in ShareLaTeX? ;)

I once got as far as writing and http server that used the flexibility of TeX macros to turn headers like 'content-length:' into TeX commands that recorded their value, and then processed the incoming request as if it were TeX code. It wasn't pretty...

This is obviously impressive. AVR is surprisingly annoying to emulate! If you're looking to emulate enough to run C on, two platforms that are significantly less painful:

* MSP430, whose instruction set fits on a single Wikipedia page while simultaneously being nicer to program than AVR

* The c4 compiler's stack machine VM, which was designed specifically to be a minimal machine on which to run C in the smallest number of lines of code.

I'm not very familiar with the AVR instruction set, what makes it difficult to emulate?

AVRs have a few quirks because the original ISA didn't consider parts with more than 8K program memory, so later some longer jumps where tacked on. A few instructions has a bunch of special cases for some common operations (eg. bit-based access to some, but not all, IO registers). It is kind-of-but-not-really orthogonal with comparatively many instructions for an 8 bit controller (about ~120).

Not sure how it compares regarding "emulability".

I can't comment on the difficulty of emulation, but it's probably 'annoying' because it isn't von Neumann, which makes it a tad bit strange.

I thought the Harvard architecture was pretty common for microcontrollers, where firmware lives permanently in Flash memory. PIC microcontrollers have opcodes that are 12 and 14 bits, for example.

It certainly isn't uncommon. I didn't mean that it is strange in comparison to other microcontrollers, just that Harvard can be strange for the author of an emulator, depending on their background.

It's actually not terribly difficult. There are good references, and I remember it took me about 4 days to write the very first version of simavr[0].

What's harder to emulate are all the peripherals, and all their quirks.

In simavr the 'core' code is pretty much unchanged (apart from the odd cosmetics) in the last 7 years, while most of the work was to emulate the peripheral blocks.

[0]: https://github.com/buserror/simavr

* It's got split I and D memory.

* All of I/O space is dual-addressed through both memory map and IO ports.

* Because there are insanely simple AVR parts that don't have a stack, the stack pointer is itself a peripheral.

* Half the register file is unusable for 16 bit instructions.

* The half that is usable includes 3 register pairs that have special pointer semantics.

* To accommodate pointer/array semantics in C, those three register pairs have an almost MOD/RM-ian collection of variant loads and stores, each specialized to a particular X, Y, or Z register.

* Because the stack pointer itself is a 16 bit IO peripheral, you have to get interrupt handling implemented properly to adjust it to support the dance AVR-GCC does to set it.

* The instruction encoding itself is a shotgun blast; read an AVR disassembler's mask and lookup table logic, for instance, which is something you don't even need to do in X86.

* For all that trouble, you don't even get a consistent instruction size.

I'd still rather do AVR than X86, but perhaps not by much.

The obvious next step is to emulate ARM within it, and use it to run Linux: http://dmitry.gr/index.php?r=05.Projects&proj=07.%20Linux%20...

Would be excellent for application performance testing.

It is amazing what crazy things people do just "because we can". I love that simultaneous feeling of disgust, joy, horror and wonder. ;-)

This reminds me of https://github.com/uuner/sedtris, a console tetris game written in sed.

The code has a very similar visual feel to it: https://github.com/uuner/sedtris/blob/master/sedtris.sed

Well TeX is Turing-complete, so any computable program can be written and executed using TeX. Back in the '80s, there was an MIT undergrad named Andrew Marc Greene who wrote a BASIC interpretter in TeX (BaSiX—https://www.ctan.org/tex-archive/macros/generic/basix).

That's what the link says....

Could anyone point to the main (La)TeX files? I seem to find only documentation such as [1].

[1] https://gitlab.brokenpipe.de/stettberger/avremu/blob/f634322...

https://gitlab.brokenpipe.de/stettberger/avremu/tree/master/...

instr is a true work of art.

But can it run Doom?

https://motherboard.vice.com/read/a-catalogue-of-all-the-dev...

It can run linux on an emaluated ARM, so probably yes

There's also Stephen Hicks' winning 2008 ICFP programming contest entry, where he writes "a controller for a Mars rover" in TeX.

http://sdh33b.blogspot.dk/2008/07/icfp-contest-2008.html

Rapid Prototyping in TeX: https://wiki.haskell.org/wikiupload/8/85/TMR-Issue13.pdf

Just when you thought you've finally grasped LaTeX...

respect and awe. and a world of hell no, for me personally.

it can churn 2.5khz & took it 44 hours to calculate a 250x250 mandelbrot set.

> This picture (250x250) took 44 hours to render. The source code can be found in the test-suite directory under mandelbrot.c.

here's the instruction code: https://gitlab.brokenpipe.de/stettberger/avremu/blob/master/...

pretty nice stuff. it looks simpler than it sounds, and it's probably MUCH harder to properly implement than it looks.

I wonder whether it runs under http://manuels.github.io/texlive.js/

I like to say that TeX is the best example of an esoteric programming language which sneaked into mainstream use.

Must have been so painful!

"Surely I'm misreading that title..."

"Nope, that's really what it is..."

My response exactly.

Mine too! Just when you thought you'd seen everything LaTeX could do (and we see a lot of it at Overleaf[1]!)

If the author is reading these comments, what motivated/inspired you to do this?

[1] https://www.overleaf.com

Wut??? O_O

Reply on news.ycombinator.com