Re: [Pnet-developers] Use of ILNativeUInt vs. unsigned long in pointer casting and manipulation

[Peter Colson]

On 24/09/2004, at 2:05 PM, Rhys Weatherley wrote:

> In all cases where ILMetaUncompressData is used, the result of
> ILType_ToElement will be a simple integer again.  There will never be 
> a case
> where a "ILType *" is converted into a class pointer if it originated 
> as a
> primitive element type.  Besides fixing the "unsigned long" vs 
> "ILNativeUInt"
> problem in il_types.h, there should be nothing more for you to worry 
> about.

OK this makes sense too. I was beginning to realise that 
ILType_FromElement
results would never be used as pointers and this confirms it.

> > I'm just trying to see if there's a future porting pnet to an AS/400
> > platform that now allows for 8 byte pointers that can be bit 
> > manipulated
> > (but provides 4 byte longs).
>
> In theory, it is possible.  That's what ILInt32 vs ILInt64 vs 
> ILNativeInt is
> for.  Presumably you have some integer type (e.g. "long long") that 
> can be
> defined as an 8-byte ILNativeInt and cast back and forth to pointer 
> types
> without loss of information.  Once you have that, you're set.

Yes we've got long long and ILNative[U]Int does indeed resolve to that.

> There may be a few odd places where we have used "long" instead of
> "ILNativeInt", but they aren't as prevalent as you think.  Most other 
> places
> where "long" is used in the code, the values it holds are assumed to 
> be "at
> least 32-bits", and are not pointer-related.

Good, that's what I was hoping.

Currently I've hit an error in cvm.c ReadLong where the stack pointer is
pointing to undefined memory. I wanted to make sure our pointers weren't
being blitzed in an avoidable way.

If you have any tips for debugging cvm.c, let me know. I'm finding it
difficult to debug into all the macros used in that module. I can see
_ILCVMInterpreter being entered, lots of macro/include action and
then failure in ReadLong (this is on the hello.exe sample).

The 400 compiler should be supporting this better, but seems to have
changed for the worse in that respect from V4 to V5. D'oh!

Regards,
Peter Colson.