Oakley - Writing a New Language
After many years of moaning about various other languages I've decided to try and write my own, if only so I don't have to listen to myself moan about such things any more...
The idea to do so originally came from the Facebook group for the ZX Spectrum Next, a new FPGA computer based that is an enhanced version of the ZX Spectrum, the computer I first started to program on many years ago. People were asking if modern languages such as C# and Java would be available to code for the Spectrum Next, and others were replying that modern style languages just would not be possible to use with an 8-bit machine and people would have to code in assembly or possibly C. That sounded like a challenge to me so I started developing a new language for the Spectrum Next called Oakley.
In many ways developing a language for an 8-bit architecture is easier as people will expect less - they won't be expecting generational garbage collectors or complex multi-threading. However coding with very limited menu on a slow CPU presents another set of challenges.
Rather than compiling straight to Z80 assembler, which isn't the easiest assembly dialect in the world, I've decided to compile down to C and then use the excellent z88dk to compile the C into assembly. This allows me to concentrate a bit more on the mechanics of the language and leave the complicated assembly generation to z88dk. It also comes with an existing set of tried and tested libraries I can leverage for use. Eventually it would be great to compile straight to Z80, and ideally other architectures too.
Progress so far: I have a very pre-alpha compiler that can compile Oakley programs for the Spectrum Next, and have written a demo program that uses the Next's new sprite capability to bounce some balls around the screen. I've been stuck at or around this stage of development for a while. After getting a demo up and working I decided to get generic types working sooner rather than later which took a much larger overhaul of the code base than I hoped, especially given I added in various future road map items at the time. On top of that various real world stuff got in the way - I changed jobs and my computer died... But hopefully after my new computer arrives next week I can get a demo released to the world early February.
Releasing the compiler itself will take a bit longer. Currently the error handling isn't great - it compiles wonderfully if the program should compile, but if it doesn't you'll either get an unusual error message or a crashing compiler. Once the error handling is a bit better I intend to release a version of the compiler so people can play around with it if they so desire. Eventually when the code base is up to a decent enough standard I'll release the compiler as open source.
Expect more regular blogging over the coming months as I detail the language and the joys/pains of writing a compiler with no compiler-writing knowledge. Biggest lesson learnt so far - when writing a compiler everything is a node in a tree. If you think it isn't, you're wrong, it really is. Even when you have lots of good reasons why it isn't, it still most definitely is. And when you've agreed with me that it is, it's probably actually more nodes than you think it is.