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

9+
Liked it? Take a second to support Monkey 2 on Patreon!

10 thoughts to “Back to the future!”

  1. I am definitely excited for this, and very interested into what this may mean for the whole development pipeline. This also means less inconsistencies due to translation mismatches or C++ quirks in general, and I am hyped for it!

    0
  2. That sounds very interesting!
    What does that mean for compatibility, though? It seems that one of M2’s main strengths is that you can wrap C++ and C libraries more or less easily, enabling things like Bullet, SDL2, as well as enabling users to wrap whatever they want.

    (edit) Never mind, you addressed the question already. Seems like it would still be possible to link to external C libraries, right?

    0
  3. Not sure what to make of this, though it does make sense from the point of view of maintaining it and having an easy, quick target to build for.

    I definitely prefer the idea of building for desktop targets, and having access to native APIs, but at the same time it could be pretty cool…

    Glad to see you’ll continue support for other targets, but don’t you then gain very little in terms of effort required?

    Here’s the current version of my very WIP project built and quickly reworked for wasm (smaller terrains, mainly):

    Super Thrusting Game

    (I note the shaders don’t work… not sure if they should, or perhaps I’m using features WebGL doesn’t support?)

    Code at GitHub.

    [Pakz: Your demo runs nicely here in Firefox on Windows 7/64.]

    3+
  4. Good thing you take care of your own sanity!;) I was hoping to see a vulkan module but I suppose it is out of the todo list now. Though my targets are mobile and console, I’ll continue to back monkey2, cause it rocks! Your choice is probably a very good one for hobbyists, who don’t wan’t to install all the stuff and wait for compilation. It’ll make Monkey2 a great educational language as it should feature advanced programming concepts with ease of use at the same time.

    0

Leave a Reply