Re: [Qemu-devel] target-alpha: An approach to fp insn qualifiers

[Laurent Desnogues <laurent.desnogues@gmail.com>]

On Mon, Dec 14, 2009 at 7:02 PM, Richard Henderson <rth@twiddle.net> wrote:
> One of the other folks here (I'm sorry, I've forgotten who as I misplaced
> the mail) passed me a preliminary patch to tackle the missing fp rounding
> mode support.  That patch added helpers to change the rounding mode, and
> injected them before and after every fp insn that forced a rounding mode.

That was me.

> After some thought I decided not to pursue this method for the simple reason
> that TCG does not have native floating point code generation.

I have started implementing TCG FP, but lack the time and desire to
complete it.  The speed up was pretty good when running on an ARM
host with a fast FPU.

> Given that we
> have to call one helper routine to perform the operation, we might as well
> arrange for that same routine to handle the rounding mode manipulation.
>
> Indeed, the patch below doesn't just pass the rounding mode to the helper,
> but all of the qualifier fields.  Thus we can avoid a large explosion of
> helper routines for addt{,/u,/su,sui}{,/c,/m,/d}.

I don't really like passing parts of opcodes to helpers, but as you say
that prevents explosion of helpers.  OTOH you could do lazy calls to
helpers that set rounding modes with my approach of separating them
from computation.

I'll take a closer look at your patch tomorrow.

> To complete the patch I should add some symbolic defines for /s, /u, etc to
> avoid magic constants cluttering the code.  I should figure out what I
> should pass to helper_excp for each arithmetic exception.  I should actually
> implement the arithmetic exceptions.
>
> That said, these two patches are enough to pass the gcc testsuite with no
> regressions over native hardware.

Can you give SPECint 2K equake a try? The symptom was the presence
of many NaN's.  If you don't have access to SPEC2K I'll try it.


Laurent