[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Lightning] About work on possible mips port

From: Paolo Bonzini
Subject: Re: [Lightning] About work on possible mips port
Date: Wed, 06 Oct 2010 12:01:10 +0200
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20100907 Fedora/3.1.3-1.fc13 Lightning/1.0b3pre Mnenhy/0.8.3 Thunderbird/3.1.3

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

or direct calls to jit_pushr_i and jit_addi_p?


   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

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

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]