Re: [Lightning] Lightning extensions

[Paulo César Pereira de Andrade]

Em 21 de setembro de 2010 05:05, Paolo Bonzini <address@hidden> escreveu:
> On 09/21/2010 04:42 AM, Paulo César Pereira de Andrade wrote:
>>
>> o Added the undocumented jit_rintr_{f,d}_{i,l} interfaces,
>>   and changed jit_roundr_{f,d}_{i,l} to round ties away from
>>   zero, and updated the others to not add/sub one if the
>>   float argument is NaN,[+-]Inf or just does not fit in an
>>   integer, that is, it keeps the 0x80000000 or
>>   0x8000000000000000 result on those cases, what usually
>>   is handy, for example, in my language I treat the later
>>   specially, and use it as an overflow flag, and reconstruct
>>   an operation using mpz_t functions (e.g. mpz_set_d).
>
> This is the only one that seems a bit strange.  I'll see what I can do for
> SPARC/PPC.

  Thanks. The problem was that it would add/sub one without
checking if the float value was unordered, or, trickier to test,
without checking if it would not fit in the integer result (but
probably it would only set the carry flag when it was also
unordered). My changes basically do most of the math in
float, so, adding 0.5 to NaN or 1e128 will not change the
integer round value.

>> o Possibly somewhat big changes that unfortunately I
>>   can only test on i386, but, it is really desirable to have
>>   the low and high word of a multiplication; if it overflows,
>>   it would already have the values to setup an mpz in
>>   any language (like mine) that converts overflow of
>>   integer math into bignums.
>
> For now, you can use jit_mul+jit_hmul.
  Not a big deal :-) as multiplication overflow should not
be common, or int<->mpz conversions not common
in inner loops.

>> o Work on sin/cos/tan/exp/log etc using the x87, even
>>   for x86_64. Not needing to call the libm function means
>>   the JIT_FPR(n) registers contents are unlikely to be
>>   destroyed; issue should be somewhat small, usually
>>   just ensure the argument is in the 2-64  to 2^+64
>>   range as required by the fpu, but ensuring correctness
>>   for all input may require significant work.
>
> That existed in the past.  I think I removed it when I realized that even
> SSE would not support these without expensive inter-unit moves.

  Yes, most of my assembly knowledge did date from pre
sse times, only recently I learned that to do it in hardware,
it is required to use the x87, or, use some not so simple
code, like the glibc implementation, but that is not something
that can be inlined, and probably would justify using the
stack to transfer to/from x87/mmx (like is done in fp-32.h
in my branch, to transfer data to/from JIT_FPRET) :-)

>> o Work on complex double (and float while at it) using
>>   sse. For non sse it would require 2 registers, so, for
>>   the sake of compatibility, probably better to require
>>   2 sse registers for complex number operations as
>>   well.
>> o Possibly work on "long long" for 32 bits. Mainly
>>   because it should be somewhat simple compared
>>   to other ideas, but mostly because in my language
>>   I use it as the "generic" untyped integer value (a 64
>>   bits value), that is converted to an mpz_t on overflow,
>>   but having the overflow information directly in the jit
>>   would mean a lot less of costly tests for every integer
>>   operation.
>
> I think these are best left outside lightning.  In particular, limited long
> long support is already there via addx/addc.

  I understand. I am still thinking of how to add an external
layer to lightning, e.g. a simple register allocation schema,
for x86 could be like:

jit_foo(a, b, c) {
    /* need rax for operation */
    if (a != _RAX && !jit_reg_free_p(_RAX))
        jit_pushr_l(_RAX);
    ...
    if (a != _RAX && !jit_reg_free_p(_RAX))
        jit_popr_l(_RAX);
}

  But this can add signifincant complexity, because, it
would need several bitmask, e.g.:

int regfreemask = (1 << _rN(JIT_R0) | (1 << _rN(JIT_R1) | (1 << _rN(JIT_R2);

that should usually be the free set after jit_prolog(n) or after jit_finish
or jit_calli (conditional calls in branches are the major issue...), and
then, it would need to "automatically" mark as non free the arguments
to any jit_foo().

  It would be required to have an interface to tell a register or register set
is free, or used, e.g. a label that is a landing point of a jump, or better
yet, add a proper basic block abstraction, but generic/simple enough
that it is easy to adjust things like my language, smalltalk, lisp, etc;
If this can be done, it would be a very good "upper" layer of lightning,
maybe call it "thunder", that comes after the lightning :-)

> Paolo

Paulo