[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [DotGNU]questions about the code
From: |
Gopal V |
Subject: |
Re: [DotGNU]questions about the code |
Date: |
Wed, 5 Mar 2003 00:17:30 +0530 |
User-agent: |
Mutt/1.2.5i |
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