[Mono-dev] SIZEOF_VOID_P in the JIT

[Rodrigo Kumpera]

Hi Mark,

Do you have an idea of how big such change would be?

Cheers,
Rodrigo

On Thu, Dec 11, 2008 at 1:21 AM, Mark Mason <mmason at upwardaccess.com> wrote:

> Hello all,
>
> The current JIT code assumes that SIZEOF_VOID_P is also the size of
> registers (as per the calling convention that we're generating code
> for). There's a fair number of #if tests for this in the mono/mini
> directory (as well as in a few others).
>
> What brings this up is porting to mips/n32, a calling convention which
> uses the 'usual' 32-bit types for C language constructs:
>
>        sizeof(int) = 4
>        sizeof(void *) = 4
>        sizeof(long) = 4
>        sizeof(float) = 8
>        sizeof(double) = 8
>        sizeof(long long) = 8
>
> But where registers are 64-bits instead of 32-bits, and we need to
> generate any number of 64-bit operations under the hood for loads/stores
> into stack slots, parameter passing, return values, etc.
>
> Since SIZEOF_VOID_P is still 4 on this target,
> mono_decompose_long_opts() insists on breaking up long operands that I'd
> rather stayed together. Rather than putting in a lot of MIPS specific
> #ifdef tests in the generic code, I'd like to suggest splitting the
> current usage of SIZEOF_VOID_P -- using SIZEOF_VOID_P to represent the
> size of addresses, and a new define (SIZEOF_REGISTER maybe?) to
> represent the size of general purpose machine registers. On most all
> targets, SIZEOF_VOID_P == SIZEOF_REGISTER and everything will behave as
> it does today. For mips/n32, SIZEOF_VOID_P=4, SIZEOF_REGISTER=8 and
> we'll get the desired behavior we want there.
>
> Thoughts? Does someone see a better way to handle this?
>
> Thanks in advance.
> Mark
>
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20081211/3cfc7bc9/attachment.html