[Mono-devel-list] portability and 64bit suggestions for mini

[Laurent Morichetti]

> > - mini needs to differentiate I4 compares from native int compares.
> Could
> > use COMPARE_I4 for integers and COMPARE for native ints (and pointers).
> 
> I guess you mean the COMPARE_IMM opcode needs to be split to COMPARE_IMM
> and COMPARE_IMMP (for pointer-sized integers). The same should happen
> for some of the others _IMM variants.
> We need also to separate signed and unsigned compares for some platforms.

No, I meant 32bit vs 64bit compares. Say you want to compare (COMPARE (ref,
ref)) you will need to emit (cmp8 (ptr, ptr)) but for (COMPARE (int, int))
you'll emit (cmp4 (int, int)).

Also, is there any code to deal with sign extension when working with both
nati and int? For example (ADD (nati, i32)) => (add (nati, sxt4 (i32)))?

> > - The invoke part of mono_jit_runtime_invoke needs to be arch dependent.
> On
> > some platforms a function pointer is not the address of the code. Mini
> > should leave the invocation to arch_mono_invoke (gointer code, ...)
> 
> Uhm, I haven't thought through on this yet. There are several places
> where we invoke functions using an address for the code. One solution is
> to make all the functions that return the code address (for execution
> purposes) return the function descriptor instead. This way
> mono_jit_runtime_invoke() would work as is, right? We'll have to audit
> the code to see when the address of the code is requested and when the
> function descriptor is wanted.
> But we also have to decide if internally in the CLR we want to use
> function descriptors or not. We might want to just use the code
> pointer, to avoid the overhead on virtual function calls (function
> descriptors are just used to setup some global register for faster
> access to data: we might want to do it only during unmanaged->managed
> transitions). I guess we'd have to do some measurements here.

Right now, I emit the function descriptor at the beginning of each method
and return a pointer to it. It's just that it's only necessary when going
from static to generated code. Internal calls should never use the
descriptor to call a function as it is an indirect branch and can be very
expensive. I'll keep it that way for now (removing it would only save 16
bytes per method).

> > - On platforms where arguments are passed in registers, LDARGA_S will
> not
> > work as (LDARGA_S (OP_REGVAR)). Somehow, mini needs to box the argument
> or
> > reserve some stack space to save it.
> 
> When LDARGA is used on an argument, the argument is marked with the
> MONO_INST_INDIRECT flag: in this case the arch-specific code is supposed
> to allocate the argument on the stack (this is usually called the home
> location). The copy can be easily done in the prolog (just like in the
> x86 code, an argument that is assigned to a register is copied to the
> register in the prolog).

I'll check the flag and see if I can reserve some space at the top of the
frame for arg register boxing.

> > Is anybody else looking at a 64bit port of mini (sparc)? Would it be
> better
> > to create a 64bit branch for mini so that the current (32bit) work is
> > undisturbed?
> 
> I don't think any other port of mini to 64 bit archs is underway, yet,
> but I don't think a separate branch is needed. Most of mini should be
> (or can be easily changed to be) 64-bit clean and almost all of the
> differences can be abstracted away with a careful use of a few defines.
> You'll need 64-bit specific burg rules, but that's no issue, it can be
> done in a separate file. Also, if a 64 bit change breaks the 32
> bit mini, we can catch it as soon as it hits cvs, instead of all at the
> same time when the merge is done later.

Sounds good. The things that I need the most right now are the PCONST and
COMPARE changes.

Thanks,
-Laurent