[Top][All Lists]

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

Re: [Lightning] Lightning source compatibility

From: Paolo Bonzini
Subject: Re: [Lightning] Lightning source compatibility
Date: Tue, 21 Sep 2010 10:01:50 +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 09/21/2010 03:39 AM, Paulo César Pereira de Andrade wrote:

   Since there was not much extra comments, I added an interface for
source compatibility in my "work" branch at

It is not 100% source compatible, not really on purpose, but for inline
function arguments, it should pass the jit_state structure by reference,
not by value.

So, to use the procedure described in the lightning info, instead of

        jit_state       my_jit;
        #define _jit    my_jit
        jit_addi_i(JIT_R0, JIT_R0, 1);

now it is required:

        jit_state_t     my_jit;
        #define _jit    my_jit
        jit_addi_i(JIT_R0, JIT_R0, 1);

That's fine.  I think we should bump the version to 2.0 for this.

(discouraged) access to _jitl changes nothing, and (even more discouraged)
access to _jit now must be written as _jit->x instead of _jit.x

That's not a problem.

   If you test the code in my "work" branch, and compile it as C++ code,
another issue is that instead or writing:

        int     r0 = JIT_R0, f0 = JIT_FPR0;

it is required to write:

        jit_gpr_t       r0 = JIT_R0;
        jit_fpr_t       f0 = JIT_FPR0;

otherwise, it will refuse to compile code when passing an int where one
of the proper "register" enum types is required. For C code it is not
required, as C is not picky about mixing enum and int.

Good idea for C++.

   Another good advantage (other than strict type/value checking) is
compile time. The pseudo assembler I use as a testing tool, at

compiles roughly 5 times faster now, the significant speed increase I
suppose is because it does not need to parse a large sequence of
nested macro calls, and then a large amount of duplicated expressions.

I'm impressed, and I'm sorry I cannot review your work yet.

   It should also correct a long standing problem that I saw other people
mention, and I had myself a few times, that is expressions like:

        label = jit_beqr_d(jit_forward(), JIT_R0, JIT_R1);

and have it generate a zero distance jump.

Interesting, I've never seen it.


reply via email to

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