Re: [DotGNU]Java and Portable.NET

[Rhys Weatherley]

> > PNet is  explicitly designed to generate and to execute multiple input
> > bytecodes, translated at loadtime to a single common format.
>
> Now I'll say, maybe we should ask Rhys WHY? I thought that the purpose of his
> "bytecode JIT" was to simplify things for execution, not support multiple
> bytecodes such as Java && IL. Might be wrong though...thus the WHY?

Glenn is correct as to how pnet is designed.  It already has
some primitive support to load .class files and convert their
class/method structure into the common metadata format
used internally by pnet for IL.

This .class loader is intended mainly for use by the compiler,
which has the ability to compile programs to JVM.  It thus
needs facilities to load definitions from previously compiled
.class files.

Right now, pnet does nothing with the bytecode parts of the
methods in the .class file.  There are three approaches to
supporting JVM bytecode inside pnet:

Co-interpreter: write a second interpreter for JVM bytecodes
that works roughly like a regular JVM, but which calls out to
CLR features for class manipulation, native methods, etc.

Coder: write a JVM bytecode verifier (which is needed anyway)
which calls the coder API's to hook into the translators.  This
would produce CVM or native code as output.  The CVM can
be interpreted in the same way as for CLR.  There may even
be a small performance benefit in doing this: some JVM
instructions like "getfield" and "invoke*" are very complex,
which makes them difficult to interpret efficiently.  Converting
into CVM will re-introduce the lost efficiency.

Bytecode conversion: convert the bytecode into IL, just as
the class structure is currently converted to IL-like metadata.

This third option is actually extremely difficult because of
semantic differences in the handling of local variables in the
two bytecode systems.  A level of analysis that is close to
AI would be needed.  Therefore, one of the first two options
would be better.

If anyone is interesting in taking on these projects, then have
at it.

> > In the model being ptrposed, there is only one CLR-based run time.
>
> And why should it deal with Java bytecode, practically?

I guess Glenn's approach is "why shouldn't it?".  Innovation
happens when someone does things for the "wrong" reasons
(according to the establishment) and discovers something
useful in the process.  Treecc came about because of this,
as did CVM.

Cheers,

Rhys.