[Mono-dev] What is the state of mono interpreter ?

[Rodrigo Kumpera]

2008/9/29 Aras Pranckevicius <aras at unity3d.com>

> >> > Whatever you might be thinking I can't see why not using mono JIT
> would
> >> > be desirable.
> >>
> >> On some platforms you can't generate _any_ executable code at runtime.
> >> So there one needs either the interpreter, or full AOT. Some platform
> >> examples: iPhone, Xbox360, (maybe) PS3.
> >>
> >>
> >
> > Unless you need reflection or fancy runtime support like transparent
> > proxies, full AOT is the supported way for such platforms.
> > And even in that cases, it would be easier and better to extend full AOT
> > than bringing back the interpreter.
>
> Yes. I was just pointing out why would anyone want an interpreter.
> Full AOT would work in that case as well.
>
> However, having an interpreter would have some advantages in
> comparison with AOT (as well as some disadvantages of course). Some
> that come to my head:
> * Full AOT to another target architecture, anyone? (e.g. you develop
> on x86 machine, your target machine is ARM or PPC)
> * With interpreter, there's a shorter cycle on getting your .NET code
> to some device (think consoles here). With AOT, it goes this way:
> compiler -> AOT -> native assembler -> native linker -> code signing
> -> device. With interpreter, it's compiler -> device. One does not
> even need to have assembler, linker or code signing tools.
>


These are shortcomings of the current AOT implementation of mono
that are easier to fix than implement a fast interpreter.

Add a binary writter is not hard, just take time to do so, it happens that
we don't have enough cycles to burn on that.

The other issue would be cross AOT'ing code, which is an easier task to
accomplish than adding binary witters.



>
> For what it's worth, we're going Full AOT route in Unity for iPhone.
> But we were seriously considering the interpreter route as well.
>


Building an interpreter with decent performance takes quite some time,
not counting the time to get things like generics working properly.

The CLR bytecode format is not suitable for fast interpretation, so having
an AOT pass to convert to a more usable format would be an advantage as
well.
Something similiar to what the Dalvik VM does.

Anyway, building an interpreter isn't a simple task, specially a fast one,
which is less
portable than a JIT - most of them use hand coded assembly.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20080929/4f5c4b49/attachment-0001.html