Re: [Lightning] Lightning source compatibility

[Paolo Bonzini]

On 09/21/2010 03:39 AM, Paulo César Pereira de Andrade wrote:
>    Hi,
>
>    Since there was not much extra comments, I added an interface for
> source compatibility in my "work" branch at
>
> http://github.com/pcpa/lightning/tree/work
>
> 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
> writing:
>
>         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
>
> http://code.google.com/p/exl/source/browse/trunk/check/lightning/lightning.c
>
> 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);
>         ...
>         jit_patch(label);
>
> and have it generate a zero distance jump.

Interesting, I've never seen it.

Paolo