June 2026 – Train of Thought

Today I’ve made the 0.4.0 release of Yarg, with some important new features. As I previously noted, I wanted to rework how memory allocation worked before making this release. This required two things: ensuring corruption could not occur, and ensuring time spent in allocation was ‘constant’ (O(1) in computer science terms).

The first is complete, and all of the language can be safely used in any context. The second has two sub parts in practice – allocating memory and ‘garbage collection’ of unused memory. Today, both occur at the same time – allocation will trigger garbage collection if no memory is ready for allocation.

I’ve completed reworking the allocation process to be O(1), by integrating o1heap by @pavel-kirienko. For now, I’m deferring work on the gc part, and releasing anyway.

So 0.4.0 is not quite as far along as I hoped, because gc still runs in an unbounded time. If you trigger gc in (for example) an interrupt context, the amount of time it spends is not related to the request you made.

However, all of the code is now part of yarg, with both allocation and gc fully implemented in the Yarg VM, and not dependent on the c runtime. This means that we can make choices over time to manage this, without external dependencies. I think this means it’s time for 0.4.0. As we make releases towards 1.0, and use yarg for many projects, we can experiment with different approaches to controlling gc time. We could ban it in ISRs (and accept out of memory errors), we could time limit it, and we could also expose language constructs to allow programs to choose when gc occurs.