Avid Insight

I've blogged before about using FlashDevelop to make Flash games for free. Just for fun, I decided to do a very little project tonight... a simple slider puzzle game to challenge myself. I set myself a time target of 3 hours to build the whole thing (assets included) from scratch. Ultimately, I ended up with 3 and a half hours, but I got it working. You can see the result below...

As I've mentioned on some recent posts, I've been working on developing my own compiler and virtual machine lately. And finally, it lives! It's taken 5 months, with some language revisions along the way, but I have set out what I intended to achieve... and that's a custom programming language, compiled down to bytecode, running in a virtual machine. All of it was built myself from scratch in C++, using only a few of the standard libraries. Admittedly it's not yet complete, and I'm sure there are many bugs... but for now, it's working. :)

I program weird stuff to unwind. Lately, my pet project has been a custom programming language which I'm calling "avidscript". It is a somewhat C-style procedural language which compiles down to bytecode, and the intention is that it will execute in a stack-based Virtual Machine (VM) which is integrated into a game framework. Long term, I have designed some specs to develop it into a concurrent state/event-based language (one thread per FSM), as that will be particularly useful for programming game AIs. Anyway, I digress...

At the moment, I'm working on the low-level code generation. This is part of the compiler 'back-end'. The front-end parses the source code, turning it into an Intermediate Representation (IR) of the program. The back-end then turns the IR into final compiled code (in this case, bytecode for a VM-target... although it could equally be native machine code). I found the bytecode representation of simple loops quite interesting, particularly from an optimisation standpoint, so I thought I'd share my findings here.

Many programmers complain about how poorly C++ handles strings. The unfortunate reality is that a language with such direct memory access as C++ cannot handle strings natively, because stack memory usage absolutely must be fixed at compile-time. Or, in simpler terms, you can't expect to fit an unpredictably large peg into a small hole. The std::string class improves things considerably -- it is a very robust and efficient string class programmed by people who are cleverer than most of us can ever hope to be.

It still doesn't solve all our problems though, because it doesn't do string concatenation very well, and you can't easily convert other types (such as numbers) to a std::string. Thankfully, streams come to our rescue! They provide a beautifully simple and straightforward means of building up strings of text and sending them pretty much wherever we need them.