Re: [Lightning] Lightning extensions

[Paolo Bonzini]

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.

> 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.

> 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.

> 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.

Paolo