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

[Paolo Molaro]

On 08/03/03 Laurent Morichetti wrote:
> I started the port of mini for IPF and here are some of the issues I

Excellent!

> - MONO_NEW_PCONST needs to emit an OP_PCONST inst. Rules need to be added to
> match the new OP_PCONST inst.

Yes, I'll add an OP_PCONST opcode (that will just be a #define for
OP_ICONST on 32 bit systems).

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

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

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

> 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.
Thanks!

lupus

-- 
-----------------------------------------------------------------
lupus at debian.org                                     debian/rules
lupus at ximian.com                             Monkeys do it better