[Top][All Lists]

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

Re: [Lightning] Lightning extensions

From: Paolo Bonzini
Subject: Re: [Lightning] Lightning extensions
Date: Tue, 21 Sep 2010 10:05:40 +0200
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20100907 Fedora/3.1.3-1.fc13 Lightning/1.0b3pre Mnenhy/0.8.3 Thunderbird/3.1.3

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

I think these are best left outside lightning. In particular, limited long long support is already there via addx/addc.


reply via email to

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