Re: [Pnet-developers] Some questions regarding the code

[Rhys Weatherley]

On Monday 05 April 2004 05:12 am, Andre 'Ilu' Seidelt wrote:
> 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

Correct.

>       ILEngineType_M: managed pointer, does typeInfo mean anything?

The typeinfo refers to the pointed-to type.  e.g. "managed pointer to int32".

>       ILEngineType_O: object, typeInfo is an ILType which can be used to
>               obtain the ILClass

Correct.

>       ILEngineType_T: what is that? an unmanaged pointer or would that
>               be a native int?

"T" is more or less the same as "M".  The distinction in the ECMA spec is that 
"T" points to values on the stack, whereas "M" points to values in the object 
heap.  We don't use the distinction all that much.  From your point of view, 
the two are identical.

>       ILEngineType_MV: Managed value, does typeInfo mean anything?

It's the type of the managed value.

>       ILEngineType_Invalid: where is that used? as type for a void return?

It's used in operator tables to indicate a bad combination of types.  i.e. a 
verification error.

>       ILEngineType_TypedRef: typed reference, does typeInfo mean anything?

Nope.

> - 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?

That's more or less correct.  You don't have to use the ILCache though.  You 
can allocate the information anywhere you want.  Once created, methods stay 
around forever, so all you need is some way to refer to your information from 
CVM bytecode.  Like, say a pointer opcode argument that points at some 
separate structure that you build.

> - 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.

There are sometimes extra values.  Internalcall references have to push 
information about the current thread, which doesn't correspond directly to 
IL.  These values may not appear in the verifier's image of the stack.  The 
simplest way to deal with this is to not trace into the internalcall stubs, 
or to only trace at points where the stack contents are predictable.

> - 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?

They are generated on demand.  They represent array and pointer types that IL 
metadata doesn't directly declare as classes.  ILClassFromType takes care of 
the conversion.  ILClassToType can be used to convert back into the ILType.

Cheers,

Rhys.