Author: John

Yesterday I published the ninth edition of my Yarg Newsletter. We’ve recently landed a host based compile-to-binary option for Yarg images. This means that there is no scan-parse-compile phase for running these Yarg sources. Of course, you can still fire up an on-device REPL and code away.

I also trailed my plans to be at Open Hardware 2026 next week, and had a write up of OggCamp from last month. Subscribe here to get updates direct to your inbox!

Yarg 0.3.0 is now quite an old release, and main (our unreleased latest code) contains lots of new features developed by me and (as GitHub knows them) @dlm-yarg. I’d like to share these in a release.

A key feature of Yarg is that interrupt handling is defined in the language. Our interrupt handlers are functions like any other. Interrupts, implied by their name, can occur at any time. Most Yarg statements represent many CPU instructions, and if an interrupt occurs during a sequence that is altering state the interrupt will refer to, the handling function needs to be delayed until the sequence completes. This imposes constraints on the implementation, as we want any such delays to be minimal and clearly documented.

The most notable state today that is altered in a multi-instruction sequence is the heap, when allocation occurs. Up to Yarg 0.3.0 this was easy to avoid in interrupts because very few operations allocated on the heap. It was my plan to eventually flag at compile time if your function contained code that triggered a heap allocation. I imagined straightforward style guides to help developers avoid this problem.

Two things have changed since Yarg 0.3.0. Firstly, the language has grown features (a richer type system, unbounded integers) that currently require heap allocation. Secondly, I’m becoming convinced that even a simple style guide is unwanted complexity, so I want to eliminate any special casing for interrupts. Yarg interrupt handlers will allow any usage of the language in them.

Given that our current development code contains errors in some interrupt cases that should reasonably work, I want to hold off an 0.4.0 release until this is fixed. As I wrote this post, I was struck that none of the current tests reliably failed, so I’ve added one that currently does not run to completion.

I think there are two related strands that will address this:

1. Ensuring the full language implementation is ‘interrupt safe’, unlike the approach in Yarg 0.3.0. In that release a few exceptions were permitted, and implicitly forbidden from use in interrupts (I never wrote the style guide for that!). Making all operations interrupt safe will require implementing a new heap allocator that avoids any unbounded delays before interrupt functions can be called.
2. Reducing the current reliance on heap operations for common language features. Some uses can be eliminated, and others special cased.

Clearly these two are inter-related, and will evolve as each makes progress.

I attended OggCamp 2026, for the first time. I thoroughly enjoyed the experience, and was pleased I could share a talk. My presentation was: “The Yarg Language: Over Engineering a Model Railway Controller”. With thanks to the organising team for the event and the livestream, here is the recording they shared:

Unfortunately I forgot to turn on the mic, so my intro slide didn’t make it into the recording.

If you’d like to follow the links, the best start is yarg-lang.dev, and the previous version was given at Raspberry Pint.

Here are the slides: