Re: [DotGNU]WHere does CVM fit into the pnet picture?

[Gopal V]

Adding my bit to the conversation, inline

If memory serves me right, Rhys Weatherley wrote:
> > I would like to ask a very quickly if my understanding of
> > how CVM fits into the Portable.NET picture is correct.  It seems to me
> > that the high-level compilers compile into CVM before a second phase
> > compiler converts CVM into an intermediate format (currently either JVM
> > BC or .NET IL).

CVM is for the engine ... it's a pointer based opcode and has no file
format (and according to Rhys it would be faster to convert to CVM than
precompile it and load off a file.., hmm.. maybe that's coz CVM conversion
is done while verification , making it very very low overhead)

The advantage of using CVM is that it's non-polymorphic and has no 
further verification or checking done on it (JVM had a similar set of
"Quick" opcodes) . Also the format is therefore optimised for speed ,
for example CVM implements field loads and stores as memory offset writes
instead of as "object based" instructions.

Also CVM has a set of inline opcodes like "COP_INLINE_STRING_EQUALS" which
enhance the speed of string comparisons enormously by avoid the overhead
of method call and the thunk between the IL code and internalcall code.

Have a look at the entire boiling at pnet/doc/cvmdoc/ (or at the inline
code in pnet/engine/cvm_*.c)

> a sequence of CVM instructions in memory.  The CVM instructions are then 
> interpreted.  CVM is used solely inside the engine - it is never visible to 
> outside tools like the compiler.

CVM instructions need not always be "interpreted" directly ..  the unroller
is a CVM "compiler" (just like a JIT "compiler") but it converts CVM opcodes
into native .. Thus performing a 2 step conversion.

IL -> CVM -> (x86|arm)

The advantage of this approach is that you can construct a full JIT as set of
peices instead of being "All or Nothing" approach taken normally. So the 
normal Portable.net engine on x86 processors are a mixture of "CVM" and 
"x86" engines , with cross jumps between both modes. The unrolled x86 
engine does have register allocation and stack items (and locvars) passed
by register giving a step up on speed. 

This approach favours "portability" and "short development time" .This
simplifies adding new unrollers (as you don't have to do the entire 
JIT at one go).

> The compilers do have an intermediate form of sorts - the abstract syntax 
> tree 
> that is managed by treecc.  But that is a separate issue from CVM.

The multiple backends in the compiler uses the AST with new visitor 
functions for each output format ... This ensures better code re-use.
The VB compiler and the C# compiler (and all the other compilers) use
the same backend codegen with no modifications. TreeCC ensures that
you can have virtual operations making this a lot more flexible than
plain C , ie that is compiler specific nodes works seamlessly with
the basic codegen backend . (have a look at pnet/cscc/bf/bf_codegen.tc,
for a compiler owned codegen,the Managed C for a mixed codegen and
C# for a fully backend codegen) . It's all very very flexible...


*ahem* ... I think a dia or other picture of how pnet engine works
is in order ?

Gopal
PS: I wonder what ^Tum would have faced if he had to hack "monitorenter"
    for x86 , Arm and god knows what JIT seperately :)
-- 
The difference between insanity and genius is measured by success