For the time being every one at MoSync AB is hard at work. We're getting closer and closer to the stable release which is scheduled for the middle of February and have a feature freeze at the end of this week. So I'd thought I' take a break from development and write more in depth about how MoSync really works.

MoSync is not one thing, it is a series of tools and support systems that let's you run the same code on many different mobile devices without having to worry about anything other then maybe screen size.

My first thought when I first encountered MoSync was, "Why? Doesn't J2ME do the same thing?"

The short answer is ... no. The long answer is that in theory it should, but there's just too much fragmentation in the J2ME space, everything from which base APIs are supported, to which extensions are supported. Then there's also the problem that not all phones support J2ME, iPhone is one such example. Palm's WebOS is another.

Another issue in the J2ME space is that everything happens very slowly. Each new API has to go through a complicated process in which many people are involved and everyone has to accept the specification. Then there's also the issue that J2ME requires a virtual machine to run your code on. This virtual machine is always pre-installed on the phone shipped out of the factory and it will more or less never support new APIs.

MoSync takes a different approach. It doesn't need anything pre-installed and it too is based on a virtual machine (or rather virtual platform in the MoSync case), but with one huge difference. Bear with me while I'll guide you through what actually happens when from the moment you compile a program to the moment when it first runs. Below is an overview of of the process as well as the tools involved.

GCC

When you compile your code, a modified GCC compiles your code to MoSync IL code, that is, it produces assembly files for the MoSync virtual platform. Unlike the norm, this virtual platform is register-based with a lot of specialized registers that make it very simple to analyse the produced code and recompile it to a real architecture, or simply translate it to another high level language, such as Java. The MoSync IL is extremely rich, so much so in fact, that you could pretty much convert it back to its original source form, if you desired to.

Libraries

The MoSync standard libraries handle all the ordinary things you'd like to do, such as input, output, syscall to the runtime, GUI handling, and so on.

Pipetool

In pipetool, the MoSync IL is combined with the required pre-compiled MoSync libraries such as MaUI, MAStd, and MAFS into one big monolithic program, like any ordinary linker does. But that's where the similarities stop. Pipetool is a cross between a compiler and a linker and it performs further code analysis to extract execution paths and data flow and to further optimize the code to make sure it runs as efficiently as possible. After that either a binary version of the IL code is produced in which all the meta data is stripped from, or if required, Java code is produced instead.

Static Java

If Java is produced by pipetool, it is compiled together with either one of the J2ME Runtimes (there are more than 20 of them) or the Android runtime, after which the byte code is ready run on a Java device, or if android, it's ready to run on a Dalvik device. Static Java has very good performance compared to hand written Java, so the performance loss is very small.

MoSync IL

If on the other hand, MoSync binary IL is produced by pipetool, it is bundled with the correct runtime for the device we're targeting. On desktop Windows, this is an emulator. On Symbian it is the correct Symbian runtime, the code is then recompiled at startup so the performance loss is quite small. On Windows Mobile, it is of course bundled with the correct windows mobile runtime (wm5, wm6.1, wm 6.5) and recompiled on startup. On Moblin it is run on MoRE, but will soon have a recompiler as well. And the same goes for any new platform that is added.

The assembly form of the MoSync IL is quite different from the binary form. The assembly form is extremely rich in metadata, as previously mentioned. It even has a built in scripting/macro language. Its aim is to be easy to analyse, verify and transform. The binary form has a different purpose on the other hand. Its purpose is to be compact, fast to execute and easy to transform to native code for the platform it is meant to execute on. This also means that it could change form for a specific platform, one such example is binary IL for x86, it will use less registers then on other platforms, so that it can easily be recompiled to machine code.

MoRE - the Emulator

MoRE is a virtual platform which runs MoSync IL. Some devices use MoRE as part of their runtime but usually the IL is recompiled to native code and only parts of it are used for translating syscalls and such, and of course, the recompiled code runs very quickly. Any new platform usually starts out with a MoRE implementation.

Runtimes

The runtimes do all the ugly behind-the-scenes necessities such as handling threads, syscalls, networking, bluetooth, and graphics. Basically they provide the backend that hides all the fragmentation between all the platforms.

*   *   *

And that's how MoSync works under the hood.

You might be wondering why we did not have GCC generate machine code directly. Well, here's the motivation for our solution. GCC is a beast, when you get it to work, it works well. But adding new backends is a very time-consuming, trial-and-error process. Having one backend produce code for a virtual platform which is then dealt with outside of GCC is a better solution in our opinion. You're also able to do a lot of cool things with an intermediate representation that would be much hard to do with machine code. It makes creating a debugger for it much simpler, as well as analyzing it and producing high level language from it. Of course, MoSync is much more then simply a backend for GCC. The GCC backend is just a fraction of the black box that is MoSync.

With that said, I hope you're a bit less confused after reading this than you were before.