[Mono-list] Re: can you explain what you mean?

Miguel de Icaza miguel@ximian.com
15 Jul 2001 15:04:24 -0400

> Of course,
> a good runtime will verify these declarations,
> so maybe the "proof engine" you are thinking of
> is the type checker that any JVM (and, presumably, 
> any safe CLR implementation) needs anyway (and 
> that is pretty trivial to implement).

It might look trivial to implement, but so far, it does not seem like
anyone has written a Java code generator along those lines.

I was looking yesterday at benchmarks between various java
implementations and the early JIT from Microsoft (the `dumb jit') and
it seems like the dump clr jit is outperforming java.

This is me reading the `JavaLobby' paper

> In fact, it's easy to write something that takes
> JVM bytecodes and reconstructs a parse tree (and
> even source code).  I have done it, and so have 
> many other people.  Conversely, JVM bytecodes are
> easily translated into register instructions precisely
> because the JIT knows the arity of any function
> and primitive that occurs in an instruction sequence.

The fact that you can decode *some* bytecodes into source code does
not mean that you can decode correctly *all* bytecodes that the JVM
can interpret.  

The generic example I have used it (mix of C and bytecodes):

	while (n > 0){
		ipush (n % 10)
		n /= 10;

	while (c--){

> If you know of other, concrete ways in which the CLR
> and the JVM bytecodes differ in this regard, I would 
> certainly like to know about it.  I'd also be curious 
> where this claim actually originated; is that what 
> Microsoft is saying about the JVM?

I dont think Microsoft is saying anything about the JVM.  But just
like you, I was wondering why people said `the CIL bytecodes are good
for JITing'. 

The answer is trivial once you read the BURS research papers (the web
site has the links) and the list of restrictions that CIL imposes on
the bytecodes.  You can now precisely track the requirement to the
algorithms being implemented for instruction selection.

Look in Partition I for a set of restriction on CIL byte code.