[Mono-dev] SIZEOF_VOID_P in the JIT

Mark Mason mmason at upwardaccess.com
Wed Dec 10 22:21:59 EST 2008

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.

More information about the Mono-devel-list mailing list