[Mono-dev] SIZEOF_VOID_P in the JIT

Mark Mason mmason at upwardaccess.com
Wed Dec 10 22:56:40 EST 2008


Hello,


On Thu, 2008-12-11 at 01:40 -0200, Rodrigo Kumpera wrote:
> Hi Mark,
> 
> Do you have an idea of how big such change would be?

There's ~154 uses of SIZEOF_VOID_P under mono/.

What I'm proposing would actually leave them all alone to begin with -
and I'm fairly certain that most all of them would never need to be
touched.  I'd just introduce a new define, and propagate it through the
code base on a case-by-case basis as I find pieces that do need to be
updated.

For everyone except mips/n32, SIZEOF_VOID_P == SIZEOF_REGISTER, so even
when I do the substitution, there will be no change in behavior.

But - before I go introducing such changes, I'd like to get a blessing
on the concept, and on the name of the new macro.

This just seems a lot cleaner to me than putting:

#if defined(__mips__) && (_MIPS_SIM == _ABIN32)

tests in the non-mips specific files instead.


Thanks,
Mark

> 
> 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
> 



More information about the Mono-devel-list mailing list