[Mono-devel-list] Mono Interpreter: Dietmar's idea.

[Paolo Molaro]

On 07/15/03 Bernie Solomon wrote:
> While it is true the current interpreter tracks types on the stack I don't
> think this is the major reason for slowness from what I saw (not to say if
> instructions were processed such that type checks were unnecessary it would
> not be faster). The reasons I noticed are:
> 
> - Continual looking up of tokens to get methods/fields/string constants and
[...]
> - Copying arguments. I am not quite sure why arguments need to be copied
> from the callers stack to another block of memory for the callee. At least

The spec says that there is an implicit cast when passing an argument to
a function that takes, like, a byte (because on the eval stack the data
is a int32). So you can avoid the copy in most cases, but not all.
The issue is the same for stores to the local variables, that is why
stackval_from_data and stackval_to_data are used and they are actually
the main speed hit in the interp as I recall.

> - Valuetypes keep hold of their class with the value. As far as I can make
> out this is not necessary as it the actual field is only used in two places:
> INITOBJ - which has the class as a token which is currently ignored but
> could be used instead - and in LDFLD where we can use the class from the
> field (I think). So I think stackval can have this removed and be reduced in
> size.

It was there also for IL validation.

> Given the current interpretation technique I think all these can be improved
> though no doubt there are other areas - and maybe this is all irrelevant
> if a completely different style of interpreter is used.

Mint is a tool to bootstrap mcs/corlib and and easy way to get some
exposure to the mono internals when first porting mono to a new
architecture. Of course it would be nice if it was faster, but the time
is better spent porting and improving the JIT.
I also don't think it's worth doing an interpreter with the JIT's
internal representation (that could maybe work side by side with the JIT
itself). The complexity increase is not worth it and it's much more work
than people think (on the same size as doing a complete port of the JIT
to a new architecture).

lupus

-- 
-----------------------------------------------------------------
lupus at debian.org                                     debian/rules
lupus at ximian.com                             Monkeys do it better