Back to the future!

Hello all,

I have been thinking a lot lately about where to take monkey2 (and blitz research) next and I have decided to concentrate most of my efforts on a single target.

I am very happy with most aspects of monkey2, but one thing I think I seriously misjudged was the cost of using c++ as an intermediate format. I still believe this was the only practical way for a one man show like me to approach the problem of generating output for a wide range of targets, but it came at a greater cost than I would have liked. For starters, there’s the admin cost of users even having to deal with 3rd party tools, eg: installing msvc or xcode etc (and keeping them up to date). And then of course there’s the cost in terms of build times – yes, things are better after that first build, but c++ compilers are just not that fast. I guess professional programmers are used to non-trivial build times – and the admin thing too – but still, that doesn’t make it right – monkey2 *should* be simpler to use and FASTER! Finally, squeezing GC, reflection, debug and typeinfo etc into c++ was not particularly pretty. Features like this are IMO more easily done at an even lower level than c++.

So what I am planning to do is write a backend for monkey2 that allows me to skip the c++ compiler/linker completely, pretty much the way blitz3d did (and sort of bmx, although that still used ‘as’ and ‘ld’). This should dramatically improve build times, and simplify a lot of the low level stuff like debug, gc, reflection etc. This implies targeting one flavour of asm or possibly even some sort of IR like LLVM bytecode, but I have decided instead to concentrate my efforts here on writing a backend that produces web assembly.

Web assembly (or ‘wasm’) is a virtual assembly instruction set (although it’s stack based) and is what the emscripten target (eventually) produces, and it may seem like a weird choice given my comments about c++ build times above (emscripten has probably the worst build times), but wasm is nice and clean and simple and open and it should be possible to write a super fast wasm compiler fairly easily (ha!). In a way, what I would like to end up with is something as fast and painless to use as monkey1’s html5 target, but with monkey2’s language and modules.

So why wasm? Why not x64 or arm etc? Mainly because wasm is IMO the most interesting target AND the target I would most like to see succeed. It’s modern, nicely designed, well docced, free/open and no one ‘owns’ it. And, theoretically at least, wasm apps ARE multitarget and can run on every monkey2 target. In practice of course, there are likely to be issues, but hopefully not for long. Producing wasm apps also means we can leverage everything available in the browser (which is a lot, with more being added all the time), and still be able to link with (prebuilt) c++ monkey2 libs like chipmunk, assimp, bullet etc when necessary.

I do plan to continue supporting monkey2 on other targets, and will continue to do so for as long as people keep posting issues at github. But for the sake of my own sanity and given the direction I’d like to take with monkey2 (faster, simpler, back-to-the-future etc) I will be giving wasm development precedence in future.

You can find out more about WebAssembly here:

https://webassembly.org/

Here’s a cool, simple wasm IDE:

https://webassembly.studio/

And indeed, one of my first missions will be to get ted2go running in monkey2-wasm, although it will take some non-trivial work to get fibers/coroutines working. I’m pretty sure it’s do-able though – more nitty gritty on this in a future update!

Of course, monkey2 already produces very nice wasm apps, eg:

http://monkeycoder.co.nz/bananas/Plane/Plane.html

If you have an links to other monkey2 wasm demos, please post them below.

Bye!
Mark