[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Paulo César Pereira de Andrade
Subject: Re: [Lightning] Re: Update on testcase [was: sse instructions and gcc warnings]
Date: Tue, 10 Aug 2010 12:11:06 -0300
User-agent: SquirrelMail/1.4.19

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:
  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,
    jit_ldxi_i(JIT_R0, JIT_V1, offsetof(implicit_dynamic_value, type));
    label_not_int = jit_bne_ui(jit_forward(), JIT_R0, t_int);
    label_int_next = jit_jmpi(jit_forward());
    label_not_float = jit_bnei_ui(jit_forward(), JIT_R0, t_float);
    label_float_next = jit_jmpi(jit_forward());
  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
    label = jit_bne_ui(jit_forward_near(), ...)
    other_label = jit_jmpi_near(jit_forward_near())
  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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]