Re: [DotGNU]questions about the code

[Gopal V]

If memory serves me right, imateos wrote:
> 1) The macros for generating x86 code are in the file "x86_codegen.h", 
> but when are they called??. Once the IL code has been translated to CVM, 
> the function "_ILCVMInterpreter" is called, but what goes on?? The only 
> actions that are made in the diferent cvm*.c files are referent to 
> modify the stack an the PC, but no x86 code is generated.

  
  /**
  * <opcode name="unroll_method"
  *         group="Miscellaneous instructions">
  *   <operation>Mark a method for unrolling</operation>
  *
  *   <dformat>{unroll_method}</dformat>
  *
  *   <form name="unroll_method"
  *         code="COP_PREFIX_UNROLL_METHOD"/>
  *
  *   <description>The <i>unroll_method</i> instruction is
  *   used in direct code to trigger native code unrolling.
  *   <p/>
  *
  *   Unrolling converts fragments of the method into
  *   native code for the underlying CPU, to speed up
  *   execution.</description>
  *
  *   <notes>There is no bytecode format for this
  *   instruction, because unrolling is not possible
  *   with the bytecode encoding.<p/>
  *
  *   In a method that can support unrolling, the
  *   <i>nop</i> instruction is used to mark
  *   a label, so that the unroller can process labels
  *   in a single translation pass.  The <i>prefix</i>
  *   instruction is used to mark the end of the method's
  *   code, so that the unroller knows where to stop.
  *   </notes>
  * </opcode>
  */

Which is where the _ILCVMUnrollMethod() is called from. The unroller
is a cool thing to have because it is a mini JIT but does not have
the "all or nothing" problems full JITs face.

Generating the CVM opcodes for unrolling makes lots of sense here 
because I think we could even have an ilrun --no-unroll mode which
will disable the generation of the unroll instructions at runtime.
(same applies for the --method-profile etc..)

> 2) When the image is loaded into memory by the function 
> "ILExecProcessLoadImage", after the loading it seems that we've got the 
> metadata information duplicated? I tell this because we can find it in 
> tokenData[] and image->data . it would be possible to delete some 
> information from the image structure to optimize space??

As far as I understood , the tokenData is calloc'ed stuff and the 
image->data is mmap'ed stuff. The former being an index of tokens
rather than data itself. IMHO , these are 2 different data structures.
But the question of whether modifying loaded images are possible
are left for the philosophers ("who get drunk and fight for forks").

The possibility of using read only shared memory segments for images 
running in different instances is there. That would be of great advantage 
to the DGEE which runs about 12 instances of ilrun at the same time . But 
I don't want to muck around with that right now .( though I've thought
about fork()ing ilrun and using the "copy on write" to save memory for
the DGEE :-) 

All those are (even in my opinion) impractical and crazy.

Gopal
-- 
The difference between insanity and genius is measured by success