Re: [Lightning] Re: Update on testcase [was: sse instructions and gcc warnings]

[Paulo César Pereira de Andrade]

Paolo Bonzini wrote:
> Hi Paulo,

  Hi Paolo,

> as you can clearly see I'm a bit busy, but I still read your posts with
> much interest and will apply the patches.

  I understand, no problems :-) I am not going to make use of most
of what is being tested soon, but at some point I hope to have some
kind of register allocation logic during jit generation.

  I will try to extend the current load/store test case to also check
for some register "ping pong" and/or value swapping to ensure there
are no cases a register value can get clobbered by lightning. Also,
since I plan to write soon some test for other operations, may need
some reorder to not have everything in a single file, as for example,
brute force testing all combinations for just 'add' may require as
much code as the current load/store test case.



  Some brainstorming about usage of lightning in my virtual machine:

1 While one should avoid certain register combinations for certain
  operations, it could be useful to have some kind of logic to tell
  lightning a register is free. Example:
  jit_alloc_reg(JIT_V?|JIT_R?|JIT_FPR?|<others>)
  jit_free_reg(JIT_V?|JIT_R?|JIT_FPR?|<others>)
  that would be a noop or set a bitmask in _jitl, and then, it could
  check that bitmask to know it does not need to push/pop a register,
  so one could have something like:
#define jit_replace(s, rep, op) \
        (_jitl.used_regs & (1 << (rep)) ? jit_pushr_i(rep) : 0, \
         MOVLrr((s), (rep)), op, \
         _jitl.used_regs & (1 << (rep)) ? jit_popr_i(rep) : 0)
  (macro names free, e.g. jit_use_reg, jit_pin_reg, etc, but only
   brainstorming, and this logic possibly only useful for i386)

2 Some way to use short jumps, again probably only useful/applicable
  to i386. Reasoning is that a lot of code is duplicated, so, it would
  be known beforehand that it will generate a lot of identical jumps,
  example:
    jit_ldxi_i(JIT_R0, JIT_V1, offsetof(implicit_dynamic_value, type));
    label_not_int = jit_bne_ui(jit_forward(), JIT_R0, t_int);
    <<handle-common-case>>
    label_int_next = jit_jmpi(jit_forward());
    jit_patch(label_not_int);
    label_not_float = jit_bnei_ui(jit_forward(), JIT_R0, t_float);
    <<handle-common-case>>
    label_float_next = jit_jmpi(jit_forward());
    jit_patch(label_not_float);
    <<call-fallback-C-code>>
    jit_patch(label_int_next);
    jit_patch(label_float_next);
  this is almost a cut&paste of some code in my vm, and it can generate
  a very large number of duplicates of this one. Could require something
  like:
    label = jit_bne_ui(jit_forward_near(), ...)
    ...
    other_label = jit_jmpi_near(jit_forward_near())
    jit_patch_near(label)
  and those could just be aliases if there are no near jumps

3 64 bits values in 32 bit arches. Ok, that is kind of asking too
  much :-) That would mean the requirement of something like defining
    jit_ldxi_l(low_reg, high_reg, base_reg, index_imm)
  and a huge amount of headaches for other operations. Also, clobbering
  the "l" modifier may not be a good idea; next good one would be "q",
  e.g. jit_ldxi_q(...), but then, I would ask to use "q" for 128 bits
  values, e.g. SSE registers :-)

4 Following idea in (1), use that bitmask to choose which calle save
  register to push/pop. This could significantly improve my current
  implementation (but be less noticeable later when more stuff is
  written in lightning), as the current implementation calls a lot
  of C functions; lightning basically only glues these calls (dynamic
  typing is not the fastest thing, but I am sure the mix of dynamic
  and static typing I am using has uses...)

5 Possibly some jump table support if applicable. I did not yet
  implement any because I am still maturing some ideas, but my idea
  is something like creating a vector where I store labels, and use
  the implicit dynamic type as offset to select jump address
  (after checking bounds of course).



  I am sure I will come with more brainstorming ideas later.

> Thanks!
>
> Paolo

Thanks,
Paulo