Re: [Lightning] About work on possible mips port

[Paolo Bonzini]

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.

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

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

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

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

Paolo