[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:
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
- Re: [Lightning] Re: Update on testcase [was: sse instructions and gcc warnings], Paulo César Pereira de Andrade, 2010/08/06
- Re: [Lightning] Re: Update on testcase [was: sse instructions and gcc warnings], Paulo César Pereira de Andrade, 2010/08/10
- Re: [Lightning] Re: Update on testcase [was: sse instructions and gcc warnings], Paolo Bonzini, 2010/08/10
- Re: [Lightning] Re: Update on testcase [was: sse instructions and gcc warnings],
Paulo César Pereira de Andrade <=
- Re: [Lightning] Re: Update on testcase [was: sse instructions and gcc warnings], Paulo César Pereira de Andrade, 2010/08/10
- Re: [Lightning] Re: Update on testcase [was: sse instructions and gcc warnings], Paulo César Pereira de Andrade, 2010/08/10
- Re: [Lightning] Re: Update on testcase [was: sse instructions and gcc warnings], Paolo Bonzini, 2010/08/10
- Re: [Lightning] Re: Update on testcase [was: sse instructions and gcc warnings], Paulo César Pereira de Andrade, 2010/08/11
- Re: [Lightning] Re: Update on testcase [was: sse instructions and gcc warnings], Paolo Bonzini, 2010/08/15
- Re: [Lightning] Re: Update on testcase [was: sse instructions and gcc warnings], Paulo César Pereira de Andrade, 2010/08/15