[Mono-devel-list] Prevalence of pointer-integral-pointer casting in mono?
pcolson at connexus.net.au
Mon Aug 9 01:29:29 EDT 2004
> 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
>> 128-bit platform as such, however pointers are represented as 128-bit
> How much of that is the compiler doing weird things or the cpu
> that setup (like, for example, how function descriptors are used on
The architecture is PPC, so the 128-bit pointers are at a much higher
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
> 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
> long (even if it might not be the default). So this is another path
> 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
using 'teraspace' compiler options which I am currently doing. However,
the OS version that I'm currently using this still results in 128-bit
targeting a later version OS we can get 48-bit pointers which could be
(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
> hold a pointer (similar to how 64 bit ints are handled on 32 bit
> 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
I could still still be making quite a few changes.
> 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
> End of Mono-devel-list Digest
petercolson at mac.com
More information about the Mono-devel-list