2026 NewsLetter - Nearing release

[gamblevore]

So, after 3 years of this ASM work (plus the nilchecker and various other bits)... the compiler is nearing release status.

This will be a beta-release. So... the first thing will be to get testers in... people who don't mind there being bugs, and wanting to help find and fix bugs.

If anyone wants to be a beta-tester, its already a good time to sign up.

...

The current state of the project, is that the compiler is in a very good state. Mature, fast, stable, feature-rich.

The ASM-backend seems very good also. It generates well-optimised code. Its still missing a few obvious optimisations, but its doing about 93% of the optimisations I wanted to add. The code-base looks good, its understandable (mostly), and it runs fast.

I guess the inlining is super-complex, but apart from the optimisations, the code is straight-forward.

The IDE Perry is also in a very good state. There are 5 remaining GUI bugs I want fixed. They aren't "real killer bugs" but more like glitches. The biggest one is the text-editor. When you alter any text, the entire "line objects" array is removed and rebuilt. This isn't visible to you most of the time... but when looking at compile-errors, it is visible, because the "line objects" contain the compile-errors. Theres two ways to fix it. One... save the old lines and copy the errors across. Or two... alter the line-objects in place. The second is faster, but hard to do. Thats the biggest GUI bug. Nothing killer-status. And a minor nuisance.

It just means when compile errors show up in the text-editor, they disappear once you edit the text. (But the errors still show up in the error-list... which is a listview to the left of the text-editor. and the errors will come back anytime you resave or recheck your code.)

So overall... Perry is in a good state also.

Perry's debugger isn't working 100%. More like 80%. So not bad! You can already compile and run, the program will stop at breakpoints, and display the stack and variables. What is left?

• Altering breakpoints in live-runs
• Altering variables
• Making the debugger GUI more attractive.
• Probably some other tweaks I didn't think of yet.

I have also some new debugger features I want to add, but they aren't necessary for a beta release. Stepping backwards in code is going to be my biggest feature! I'll put it off till later in 2026, after the OpenCL release.

...

As for Cake/VM... I've already got a lot of work done. My DebugFormat, seems 100% complete. The only missing bits might be feature additions. It's got two kind of source-maps even. That is mapping from source-code to the compiled binary, and mapping from the compiled binary back to source-code. Both are necessary.

My DebugFormat has got listings for all the classes used, the property layout, globals and their layout, local variables and their scope, type-information for all of these... and more bits and pieces. So it works quite well.

Its got memory protection built in, so the debugger can inspect bad pointers without crashing. And the code itself is memory protected, so you can't trash your code by overflowing the stack.

The linker is also done. I did this as run-time linking only. Theres no compile-time linking, unless you count inlining (haha). This is to aid in making Speedie moddable. Like Java is, but hopefully better. Minecraft became popular due to mods. I'd like Speedie to do the same.

Runtime linking is easy anyhow, you need to go over each instruction ANYNOW for linking to libraries, so why not check for linking to internal functions too? Its literally just a lookup from a linear array. Just adding numbers, then reading, basically. So we get run-time linking almost for free.

The VM itself seems very good. Seems to do everything. I think the only outstanding parts are Vector optimisations. Vector math can be... large. Its doing some of it, but not all! For example: "v4[1]+=x" that isn't a single instruction. Its 3. No good!

But othertimes it is good. Anyhow so I'll fix those...

...

So What is the biggest remaining effort to do?

Basically... finishing off the ASM compiler. While my simple tests work... I can see globals+recursion+cpp/spd functions all working OK, constants and all that. Branches and loops work nicely... thats not really enough. A real compiler has to test all the edge stuff.

I still have to finish off virtual functions, and function pointers in general. Which is complex! Because... We want to call a function, but there are two ways of possibly calling it, depending on if its a cpp or a spd function-pointer.

Also... calling spd from C is... not going to be so easy (for me) to get working. But it seems necessary, because how else will Speedie's GUI call your virtual functions? So thats one more thing to do.

I also need to go over all my C++ struct/class wrappers, and make sure they are properly described in Speedie. That... or generated BY speedie. (Currently, Speedie relies on gcc to get the property offsets correct. But with speedie's own ASM, it can't do that.)

Its all very doable. But there is a large volume of remaining work. Maybe a few months for finishing off all the details, bits and pieces.

The main goal, is to get speedie itself... running and working, from within it's own VM.

Once Speedie can run within Cake... I'll know that the compiler is good!

That... and also being able to debug the entire thing from within Perry.