[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Lightning] About work on possible mips port
From: |
Paulo César Pereira de Andrade |
Subject: |
Re: [Lightning] About work on possible mips port |
Date: |
Wed, 6 Oct 2010 16:18:40 -0300 |
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