Show HN: AVR-VM – VM with JIT-compiler for ATMega32 written in Rust | Hacker News Reader

Show HN: AVR-VM – VM with JIT-compiler for ATMega32 written in Rust

github.com

78 pointsMackieLoeffel11 comments

I remember coding for atmega at university and we had to use these super shitty windows tools.

This is awesome!

Well, actually things like an avr-gcc toolchain, and other open source utilities have existed for a long time, so you can use your operating system of choice for attiny/atmega development, with no need for Atmel Studio.

This JITs & executes basic blocks but that doesn't seem correct with interrupt handling. Interrupts can of course occur in the middle of a basic block, which isn't handled right now from what I can tell?

It is a difficult problem to get cycle correct interrupts, no doubt.

I don't know anything about the architecture, but if an external source is causing the interrupt, how can could you observe that the interrupt was delayed until the end of a basic block? You can only run for so long before you reach the end of a basic block, so can you tell the nanosecond difference? And doesn't the routine triggering the interrupt wait until the interrupt is serviced, so how can it tell the difference as well?

Yes, thats exactly the reasoning, why it isn't a problem to handle the interrupts only between basic blocks. Qemu does something similar. The ATmega32 makes it easy in this regard, because it doesn't have exceptions/traps, which have to be executed synchronously (div by 0 isn't a problem, because there is no div instruction). JIT compiling for a x86 is far harder, because you have to make sure, that the traps are triggered at the correct points in time (e.g. a page fault, which happens during the fetching of an instruction).

I only know about it because I do the same thing in dynamic programming languages.

In Ruby you can redefine methods at any point, but in my implementation I only check if they have been redefined once per loop in the program. If another thread wants to redefine a method, it just waits a little while until all the other threads are ready.

This means we can basically ignore the problem of method redefinition - as we only allow it when we are ready and then we can handle it slow-time.

Well.. from the SRAM state, or any other side effect you can imagine?

Making an example that shows the difference in servicing after every cycle vs. servicing interrupts only after a basic block is trivial. Configure a timer to interrupt in 10 cycles (or X) and then have a basic block writing 1, 2, 3, .. whatever to SRAM. Read the value in the interrupt routine.

I imagine this is no big deal in x86 or similar where nobody wants or can achieve cycle-perfect interrupts anyway, but it is a common design goal for microcontrollers which have perfectly predictable timing and a lot less MHz. One cycle for an 8 MHz AVR takes 125 ns so you can imagine how servicing interrupts after basic blocks of varying length can introduce jitter into your microcontroller generated signals.

The timer interrupt is indeed a special case and not very well implemented with the JIT compiler currently. The ticker even only ticks once per basic block, not once per instruction, when jit compiling, which is definitly not what you want, when you want to have predictable timing.

But making the timing perfect was not a priority, since the programs, with which the VM was tested, also work well, when the timer interrupt only fires once in a while.

This is the great thing about a JIT though. When someone installs a timing interrupt you can switch to different code that checks the timer frequently enough for hit the target.

Well this is really impressive. Now maybe not as much as Borland full turbo Pascal environment in 32k in the old days but anyone worked on one of these chips you have crazy little resources to work with.

The VM emulates the ATMega3 on a regular desktop, it doesn't run on the microcontroller.

Reply on news.ycombinator.com