dotgnu-pnet
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Pnet-developers] Some questions regarding the code


From: Andre 'Ilu' Seidelt
Subject: [Pnet-developers] Some questions regarding the code
Date: Sun, 4 Apr 2004 21:12:33 +0200
User-agent: KMail/1.5.4

Hi,

I'm still digging in the verifier and I have some questions now that I missed
yesterdays IRC-meeting :-)

- il_coder.h: ILEngineType and ILEngineStackItem, is the following right?
        ILEngineType_I4: is an int32, typeInfo has no meaning
        ILEngineType_I8: in64, typeInfo has no meaning
        ILEngineType_I: native int, typeInfo has no meaning
        ILEngineType_F: float, typeInfo has no meaning
        ILEngineType_M: managed pointer, does typeInfo mean anything?
        ILEngineType_O: object, typeInfo is an ILType which can be used to
                obtain the ILClass
        ILEngineType_T: what is that? an unmanaged pointer or would that
                be a native int?
        ILEngineType_MV: Managed value, does typeInfo mean anything?
        ILEngineType_Invalid: where is that used? as type for a void return?
        ILEngineType_TypedRef: typed reference, does typeInfo mean anything?

- The method cache is still a mystery to me. I'll try to outline what I think
        the whole thing does and please anybody correct me :-)
        The coder calls ILCacheMarkBytecode with the current CVM-Code position 
and
        the il-offset. The cache then puts these two numbers in a compressed 
form one
        entry after another into a 64-byte array which is in the 
ILCache-struct. If
        there would be not enough space for the next entry the buffer is 
flushed into
        the aux-data of the cache page. these entries are stringed together as a
        linked list. the end of the debug-data is marked by a -2,-2 entry.
        So if I would like to store my 'evolving' knowledge of the types on the 
stack
        I could basically do the same:
                * add a function, that accepts a position in the il-code and an 
array
                        containing the stack-entries (vm-type and type-info).
                * add a buffer for 'faster building' in the ILCache struct.
                * add a list in the ILCache struct where I link the filled 
buffers.
                * add some means to iterate through the list to obtain the 
stored type-info
                        for a given IL-offset.
        Are there any reasons why I shouldn't try it that way? would a (to be
        implemented) debugger be able to use that?

- if I 'look' at the execution stack at any given point between the execution
        of two translated IL-opcodes, is it possible to have a value on the 
stack
        which would not be there if the CVM would run the IL directly instead of
        running the converted code? or is it forbidden to CVM instructions to 
put
        anything on the stack beside the values possible by the 'direct' 
execution
        of IL-code.

- some time ago I added some printf()'s in _ILEngineAllocObject() and there
        were several allocations for classes with 'special' names (stuff 
looking like
        '<class>$<number>' as classnames, I don't remember exactly).
        what are these classes, autogenerated types e.g. for arrays? where and 
when
        are these classes generated?

Thanks and regards
        Ilu



reply via email to

[Prev in Thread] Current Thread [Next in Thread]