Re: [Lightning] Lightning source compatibility

[Paulo César Pereira de Andrade]

Em 21 de setembro de 2010 05:01, Paolo Bonzini <address@hidden> escreveu:
> 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 was actually expecting it to become slower, but it seems the C preprocessor
is the problem, so, better not to abuse macros :-) But without a "high level"
compiler like gcc, using the preprocessor probably would be still be better.

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

  The problem, after macro expansions should be more like this:

label = ((exp1 ? exp2 : exp3), _jit.x.pc);
...
((int *)_jit.x.pc)[-1] = _jit.x.pc - label;

probably the problem lies in the ..., likely on some weird
result due to somehow "optimizing" code involving the
postfix "++" operator when adding data to the code buffer,
as for some weird reason, the last line, for the patch,
becomes zero, i.e.  the compiler for some thinks
label == _jit.x.pc. Interestingly, as more and more macros
were converted to inline functions, I started being able to
use local label variables to patch short (8 bits) jump in
some of the code. Otherwise, if not using a global label
variable, it would sometimes generate a zero distance jump.

> Paolo

Paulo