[Lightning] Lightning source compatibility

[Paulo César Pereira de Andrade]

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

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

  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.

  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.

  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. I suspect it could be a
bug in gcc, because most times I "corrected" it by accessing a global
pointer instead of using local variables, but it is maybe some issue
with order of evaluation. The "standard" C says arguments do not have
order of evaluation, (do not rely on side effects) and that does not
cover macros :-). Usually, it is easier for building stack frames to
parse from right to left, but afaik gcc parses arguments from left to
right; probably following "the least surprise" principle.

Thanks,
Paulo