Eniko Fox's personal blog 

If you’ve been following me on social media you may have noticed that I’ve been working on a block game for the past couple months. It is, temporarily, called Block Game. There’s even a website with an FAQ and a mini devlog feed made up of my Mastodon posts about it. But what really, is this Block Game? Where did it come from? Where will it go? I hope to explain the inspirations and vision for the game in this post.

Disclaimer: nothing in this post is a promise let alone a guarantee. This is an outline of where I intend to take things, but this is game development and things can and will change.

This is a post about my personal life and my mental health and something I want to try to fix things (even though I have no idea if it will work) and see if I can help my burnout recovery. If you’re here for my tech stuff, you can safely skip this one.

This is the third in a series of posts about a virtual machine I’m developing as a hobby project called Bismuth. I’ve talked a lot about Bismuth, mostly on social media, but I don’t think I’ve done a good job at communicating how you go from some code to a program in this VM. In this post I aim to rectify that by walking you through the entire life cycle of a hello world Bismuth program, from the highest level to the lowest.

let hello = data_utf8("Hello world!\n");

func main() i32 {
    // system call 0x10 is the PrintStr system call
    sys(0x10, hello, 0, sizeof(hello));
    return 0;
}

This code will be converted to the VM’s intermediate representation, which can then be transpiled to C, or compiled to a binary version of the IR, which the VM ingests and turns into bytecode and runs.

This is the second in a series of posts about a virtual machine I’m developing as a hobby project called Bismuth. In this edition we’re going to look at the VM’s design for memory management and safety. To start with I’ll remind you of the design goals for this VM as detailed in my last post, with those that apply here in bold:

1. Must be fast
2. The IR must be compatible with standard C
3. Can run in a browser
4. The VM must be easy to implement

Not to give away the twist, but when you combine points 2 and 4 with a VM that cares about memory safety (i.e. programs should not be able to do things like read outside of the bounds of an allocated region of memory) things can get a little bit complicated. So let’s walk through the stages of grief that I experienced and the solutions I came to during the bargaining stage when designing the memory management and safety features of the Bismuth VM.

This is the first post in what will hopefully become a series of posts about a virtual machine I’m developing as a hobby project called Bismuth. This post will touch on some of the design fundamentals and goals, with future posts going into more detail on each.

But to explain how I got here I first have to tell you about Bismuth, the kernel.