[Top][All Lists]
[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
- [Pnet-developers] Some questions regarding the code,
Andre 'Ilu' Seidelt <=