[Mono-devel-list] Prevalence of pointer-integral-pointer casting in mono?

[Peter Colson]

> Message: 1
> Date: Thu, 5 Aug 2004 12:26:02 +0200
> From: Paolo Molaro <lupus at ximian.com>
> To: Mono Development List <mono-devel-list at lists.ximian.com>
> Subject: Re: [Mono-devel-list] Prevalence of pointer-integral-pointer 
> casting	in mono?
>
> On 08/04/04 Peter Colson wrote:
>> To clarify, the platform concerned is the AS/400. It's not a 
>> full-blown
>> 128-bit platform as such, however pointers are represented as 128-bit
>> entities.
>
> How much of that is the compiler doing weird things or the cpu 
> requiring
> that setup (like, for example, how function descriptors are used on 
> some
> archs)?

The architecture is PPC, so the 128-bit pointers are at a much higher 
level. The
OS presents store as a single space incorporating memory and disk.

>  The code generated by mono can have different behaviour than
> the code generated by the C compiler used to compile mono. There is a
> more-or-less defined interface that deals with going from managed to
> unmanaged code, so if you'd need conversion code between the two worlds
> it could go there. Not saying this will be particularly easy, but it's 
> doable.
> A quick google search seems to suggest that on as/400 the address space
> is 48 bits, there are flags to compile code so that pointers are 8 
> bytes
> long (even if it might not be the default). So this is another path 
> that
> could be taken (note, I know nothing about as/400, so I may have got
> things wrong).

This may be a way out of the woods. The 48-bit pointers come with 
compiling
using 'teraspace' compiler options which I am currently doing. However, 
on
the OS version that I'm currently using this still results in 128-bit 
pointers. By
targeting a later version OS we can get 48-bit pointers which could be 
stored
(and manipulated hopefully) in long long's.

> If the above is not applicable, you'll have to support 128 bit pointers
> in the jitted code, too. This requires a bit of work if a register 
> can't
> hold a pointer (similar to how 64 bit ints are handled on 32 bit 
> archs).
> Of course, the places where the runtime assumes a pointer can be stored
> in a 64 bit int needs fixing.
> Anyway, if I were you, I'd first look at how feasible is a libgc port,
> since that is a requirement of mono anyway.

Yes, I agree with this. As Jonathan mentioned in his post there may be
assumptions that pointers are 32 OR 64 bits and even with 48 bit 
pointers
I could still still be making quite a few changes.

>
> lupus
>
> -- 
> -----------------------------------------------------------------
> lupus at debian.org                                     debian/rules
> lupus at ximian.com                             Monkeys do it better
>
>
> --__--__--
>
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>
>
> End of Mono-devel-list Digest
>
>
>

__________________________
Regards,
Peter Colson,
Carringbush Software,
petercolson at mac.com
__________________________