Re: [Lightning] About using lightning on a dynamically typed language

[Paulo César Pereira de Andrade]

Paulo César Pereira de Andrade wrote:
> Paolo Bonzini wrote:

  Just to update. Now it works :-)
  I added an extra test case to
http://code.google.com/p/exl/source/browse/trunk/check/vm-test.c

  My major mistakes were:
o Logic error in not properly matching the bytecode interpreter:
  o thread->sp should start with value thread->bp + 2
  o "add" and "lt" should be like C code:
    r0 = *--sp <op> r0;
    but it was not decrementing sp first
o And the biggest/dumbest one, was returning jit_get_ip().iptr,
  after generating code, not returning a pointer to the start of
  the code, what would execute random memory...

  And it indeed runs a lot faster then the versions with indirect
jumps, roughly 7 times faster then the equivalent test (VM == 1),
but the lightning test uses int32 values, not int64, so it loops
1e7 times, but cannot store the result in 32 bits...
  If anybody have compiled my vm, the equivalent vm test would be:
-%<-
void test() {
    int32_t a, b;

    for (a = b = 0; a < 10000000; ++a)
        b += a;
    print("%d\n", b);
}

test();
-%<-
and both the test in check/vm-test.c and the above generate the same,
truncated result.

>   I am making some beginner like questions here hoping that these
> may help others, otherwise, sorry for the noise...
>
>>>  Sorry for showing my ignorance, but what would be the best way to
>>> see the generated jit as assembly output? I think I would need that
>>> to better map "in my little mind" what code is being generated...
>>
>> You can use gdb and its disass command, or embed a small disassembler
>> in your program.  See the programs in the tests directory.
>
>   I did not write any assembly for like 10 years, just C, so I am a
> bit rusty; I am now using
> (gdb) x/<number>i code
> where number is the code length and code is the jit_insn* variable,
> and already corrected a few bugs due to incorrect usage of 'r' and 'i'
>
>>>                jit_ldxi_i(JIT_R1, JIT_V1, (int)&((thread_t*)0)->bp);
>>
>> Use offsetof here.
>>
>> I haven't tested the program, but a first hint is to run disass in gdb
>> to see whether there is an obvious problem in the code.  Another way
>> is to add an IP to your thread state and write there the IP before
>> compiling each opcode (only in debugging mode of course).  Then it's
>> clear from the disass output what IP you were executing at the time of
>> the crash.
>
>   I am attaching the first test as a C source code, and a study
> of the dump, that hopefully may help other people also.
>   I am now (re)learning the assembly syntax, to check what I am doing
> wrong on accessing the thread_t structure and reading/writing the fields.
>   This initial test is to have a small "feeling" on possibly
> adapting/changing my current vm concepts to be able to generate
> efficient code...
>
>> Paolo
>
> Many thanks for the help,
> Paulo

Thanks again,
Paulo