Question

Can anyone explain the The Runtime Architecture of MoSync?

The VM Core isn´t the Problem. I think it´s a virtual machine which is running in the java vm and interprets the code line by line.

But how is the Recompiler Core working? Is that a kind of Ahead-Of-Time compiler who compiles the app at run in native code? But then I don´t understand the pic. Or is it possible that I need the other modules of the runtime even it´s machine code?

Thanks

Answer 1

I just saw Mattias had replied while I forgot to post my reply, but I’ll just post it anyway since it elaborates further on some points 🙂

First, your C/C++ gets compiled to MoSync IL (Intermediate Language) by GCC, using our custom GCC backend. Then, for some platforms (including Android, Symbian and Windows Mobile), this IL is fed into “pipe-tool”, which is a assembler/linker/optimizer which can do different things for different platforms. Here are a few variants:

For JavaME and our soon-to-be-released Blackberry output, pipe-tool produces MoSync bytecode, which is a binary, compact, register-based representation. This bytecode is packaged together with the MoSync runtime which contains a virtual machine. When your applications starts, it reads the bytecode into memory and starts interpreting it.

For Android, Symbian, Windows Mobile etc. the process is similar, but instead of interpreting the code, what the runtime core does is to go through the entire code, and recompile it into ARM machine code on the device. Once that is done, is starts executing the ARM code it just created.

For iOS devices, the story is yet a bit different – instead of transforming MoSync IL to MoSync bytecode, the code is transformed to C source code, and an xcode project is created. There are a number of reasons for doing this. One is that for iOS, dynamically generating ARM machine code is not possible, and we since dynamically loading code is not allowed either, running as a virtual machine is pointless. Also, more on the legal side, we want to ensure that the way in which applications are produced is in full compliance with Apple’s rules and guidelines.

One of MoSync’s key strengths is this flexibility; by using a streamlined intermediate representation that any input language ultimately is transformed to and that the resulting binary for any platform is always derived from, we obtain a single point of contact between input and output. This allows us to add new input languages independently of which platforms are supported, and conversely to add support for new platforms independently of the input languages.

When people ask us “Could MoSync allow Java programs to run on iPhone?” or “Could it make C++ programs run on Windows Phone 7?” the answer is always “Yes”.

If we add support for Java as an input language, it will AUTOMATICALLY work on every platform MoSync supports.

When we add support for Windows Phone 7 then AUTOMATICALLY whatever input languages MoSync supports will be usable for that platform.

I know, it’s hard to believe, but it’s true 🙂