Re: [Lightning] More on work on lightning

[Paulo César Pereira de Andrade]

Em 28 de setembro de 2010 03:53, Paolo Bonzini <address@hidden> escreveu:
> On 09/27/2010 10:53 PM, Paulo César Pereira de Andrade wrote:
>>
>> I was thinking about it more on the sense of a function that
>> receives less arguments than those passed in registers, and in its
>> body, the register used for arguments are not used. But if an
>> argument is known to not be required anymore, the register could also
>> be used for other purposes.
>
> I had thought of making JIT_R_NUM return a variable number depending on
> the number of arguments in the current function, but actually it would
> depend also on the maximum number of arguments of _called_ functions and
> that is not available at jit_prolog time.

  I will try to restart some work in my language. Significant time already
without working directly on it... And try to work on a real code for register
allocation and generating "smarter" calls to lightning. I also need to do
better loop optimization, and add/implement the logic for type/range
inference to dynamically typed variables.

>> I just timed it on 3 different computers, and there is no difference;
>> timing of some loops running 10 million times oscillate 1-5 percent
>> to less or more, so, effectively it is the same, just that the new
>> approach should make prettier assembly dump.
>
> I'd rather avoid that.  For prettier dumps, on x86-64 you can move to a
> temporary register and push that.  For 32-bit the limited number of
> registers makes everything a challenge. :/
>
>> current code using lightning is still more the 2 times slower
>
> Did you profile to see where lightning code is spending time?

  I mean, it was known that it would become slower, as I converted it
from a single function with state in local variables, to function calls,
with state in global variables, and instead of using goto to named
labels, it is using lightning to glue calls to C functions. Right now
it is comparing apples to oranges, because the previous
implementation had reached its limit, and the code using lightning
is very far of being properly implemented.
  But I understand that, if using proper optimization, it still cannot
get much faster than something like statically typed C code
compiled with -O0 if it needs to check for overflows, etc, and if
it must keep values in heap memory updated, then it cannot
get much better than 3-4 times slower.

>>  Ok. If I could keep some states in xmm registers, it would help a lot,
>> but AFAIK there is no callee save xmm registers in the SytemV ABI.
>
> You can just throw away the stack registers and require SSE2 for 32-bit x86.
>  Anyway both the stack registers and the XMM registers are caller-save.

  That basically destroys the idea :-) For my case it would be desirable to
have callee save xmm registers, where interpreter state, that is, the vm
"implicit value" could be kept. Actually, would really require only one, but the
more the better, 2 would be better.

> Paolo

Paulo