Re: [Lightning] About work on possible mips port

[Paulo César Pereira de Andrade]

Em 6 de outubro de 2010 07:01, Paolo Bonzini <address@hidden> escreveu:
> On 10/06/2010 11:10 AM, Paulo César Pereira de Andrade wrote:
>>>
>>> For function calls, however, it would be much better (and portable) to
>>> adjust the stack pollution support so that instead of
>>>
>>>         push %eax
>>>         push %ebx
>>>         call f1           ; jit_calli
>>>         push %eax
>>>         push %ebx
>>>         call f2           ; jit_finish
>>>         add $16, %esp
>>
>> Question: You mean
>>         jit_prepare(4);
>>         jit_pusharg_i(_RAX);
>>         jit_pusharg_i(_RBX);
>>         jit_calli(f1);
>>         jit_pusharg_i(_RAX);
>>         jit_pusharg_i(_RBX);
>>         jit_finish(f1);
>>
>> or direct calls to jit_pushr_i and jit_addi_p?
>
> This.

  Ok. I did not bother much about it because it is non portable.

>>   jit_calli and jit_callr assumes calling a function with
>> zero arguments, or that the programmer knows what
>> he is doing and will push arguments and restore state
>> correctly.
>
> For 32-bit they're actually supposed to do stack pollution whenever
> possible, but you're right that it's broken for 64-bit and non-x86.

  This may be useful on some kind of "continuation" implementation,
to somehow keep pointers/references to "dead stack frames", but will
break badly, or be very hard to keep track if there is conditional code,
or loop in the middle.

>>   But I removed support for stack pollution in the sense of
>> only allowing one jit_prepare() call before a jit_finish(), and
>> added assertions that the jit_pusharg_x calls match what
>> was "declared" in jit_prepare, jit_prepare_f and jit_prepare_d.
>
> That's fine.  Have you adjusted the documentation?

  Not yet. I am trying to avoid changing as few behavior as
possible. This one I thought was required/desirable to avoid
non portable code and not actually possible to provide the proper
semantics in the work in x86_64. It still allows using push/pop
and stack adjustment manually of course, but I think it should
not be documented, as it would actually encourage it :-)

  I am also considering to remove the configure and most *.in
files, because they generate a lot of noisy in commits. Probably
better to require an autoreconf call before a make dist...

>>>> 1. move pointer to register and to indirect jump/call
>>>
>>> That's what jit_calli does for PowerPC.
>>
>>   I am mostly unsure because it could generate worse code on
>> purpose. Could expect user explicitly doing:
>>     jit_movi_p(JIT_R0, pointer_from_anywhere);
>>     jit_jmpr(JIT_R0);
>> instead of doing that without alternative, or, have some option
>> for it. jit_movi_p will already have a "complex" patching schema,
>> because it requires two instructions; one to load the top 16
>> bits and another for the bottom ones. And it will need to read
>> the opcode before the patch to decide the kind of the patch
>> for unconditional ones also...
>
> Have you looked at PPC and SPARC ports?  They do pretty much all of this
> already.

  I will look more carefully at them.

>>>>   Conditional branches must be limited to 18 bits distance, or, add
>>>> a jump over with an inverse condition and implement an unconditional
>>>> one...
>>>
>>> I think this is fine.  It's 256 KB after all.
>>
>>   In bytes, in instructions it is 64 Kb :-)
>
> Yeah, but still it's big enough for a single function.

  Sure. Actually, I think the trap on overflow could be added as some
kind of extension. It makes sense and actually could be a better approach
for some usages. My language is one case, where it would be better to
have the registers values not modified, but accessible, and convert to a
mpz_t if there is an overflow.

> Paolo

Paulo