Does machine-code needs an runtime environment? MoSync SDK_问答_开发者

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?开发者_C百科

Thanks

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 :)

One of the little know facts about MoSync is that, its not just built to be good for CPU's, its also good a transforming to other languages, for example, one of the MoSync engineers have the platform running in Javascript/HTML 5.0.

Different things happen depending on what platform you using, So MoSync transforms to its intermediate language according to what is best for the target platform.

There are also 4 different flavors of MoSync IL, they are all compatible with each other, but are modeled to advantage of different processor architectures.

The IL system has 128 registers, 6 of these are global, the rest are local to functions.

BTW, MoSync bytecode is not the same as MoSync IL, the IL being very rich in meta data.

I'd be happy to discuss the finer details or the architecture, just post your questions.

The Recompiler Core looks like a typical dynamic recompiler / JIT compiler, which recompiles code as needed. Apparently, MoSync uses a different core depending on the platform it's running on (VM Core -> Java ME, Generated Core -> IPhone, Recompiler Core -> anything else), interfacing with the runtime system as appopriate for every core, although that should be mostly transparent to MoSync's users.

The Recompiler Core is the base core + an AOT compiler, where the base core is the implementation of MoSync's syscalls. The first time the app is started the AOT compiler goes through the MoSync byte code and transforms it into native code e.g. ARM. During the transformation all of MoSync's syscalls are mapped directly to functions in the base core. The app is finally executed by jumping to the beginning of the transformed code section.

Regarding the modules. The application framework is embedded in the byte code when you link with the corresponding libraries. The syscalls and internal extensions are part of the base core and they in turn depend on the resource system.