On Sunday 17 December 2006 15:25, Eric Engler wrote: > >The libjit version of the runtime compiles the CIL instructions to > >either machine code or to a libjit interpreter, which has no connection > >to the old CVM interpreter. > > > >The compiler emits CIL instructions only, and has no awareness of any of > >this. > > Thanks, this is very helpful. So, I guess ilrun leverages libjit, and if it > chooses to use the CVM method, the CVM instructions are both generated and > interpreted by ilrun (which is using libjit)? > > Does it keep the CVM instructions in memory? I haven't seen any reference > to creating CVM files in the documentation.
The code is the documentation. :-) The "cvmc_xxx.c" files generate the CVM bytecode from CIL into a memory buffer, which are then interpreted by the code in "cvm_xxx.c". > I'd like to have 2 utility programs to decouple this to make porting > easier. I'd like one program that can convert a file of CIL instructions to > a file of CVM instructions (this wouldn't be platform specific). And then > I'd like a CVM interpreter that is not tied to a JIT module - I want this > as small as possible to ease porting. Was this type of thing done in > earlier versions of DotGNU - maybe I can get some older code to make this > easier? Speaking as the original designer of CVM (yes, I am still alive :-) ): Portable.NET generates the CVM instructions direct to memory, and the instructions themselves can include raw pointers as operands. So it isn't suitable for writing to disk and then reloading later. Also, it can generate different instructions depending upon the architecture (e.g. 32 vs 64 bit), so the CVM representation is not portable. CVM was designed this way on purpose, for maximal efficiency. The code that converts CIL into CVM can be tuned to the particular platform it is running on and the specifics of the program it is running. Perhaps not as much as a JIT can be tuned, but more than a file-based format can be. CVM itself is also not terribly useful without the full C# support environment provided by the rest of Portable.NET, so you are probably better off just sticking with CIL, and perhaps shipping Portable.NET as your portable runtime. Cheers, Rhys. _______________________________________________ Developers mailing list [email protected] http://dotgnu.org/mailman/listinfo/developers
