qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH] target/mips: Fix minor bug in FPU


From: Aleksandar Markovic
Subject: Re: [Qemu-devel] [PATCH] target/mips: Fix minor bug in FPU
Date: Tue, 19 Mar 2019 20:21:51 +0000

> From: Peter Maydell <address@hidden>
> Sent: Monday, March 11, 2019 3:48 PM
> To: Aleksandar Markovic
> Cc: Alex Bennée; Mateja Marjanovic; address@hidden; address@hidden; 
> Aleksandar Rikalo
> Subject: Re: [PATCH] target/mips: Fix minor bug in FPU
> 
> On Mon, 11 Mar 2019 at 14:35, Aleksandar Markovic
> <address@hidden> wrote:
> > I'll doublecheck, but I think "infzero" here is a misnomer.
> >
> > The variable/argument "infzero" actually denotes the cases:
> >
> >    - "Inf * Zero +/- NaN"
> >    - "Inf * Zero +/- NaN"
> >    - "Zero * Inf +/- NaN"
> >    - "Zero * Inf +/- NaN"
> >
> > "Inf * Zero +/- !NaN (let's say, normal fp)" is handled
> > somewhere else.
> >
> > Therefore, "infzero" should be rather called "infzeronan".
> > This is from what I remember, but I will reanalyse the
> > relevant softfloat code one more time.
> 
> Yes; we don't ask the target-dependent code to pick a NaN
> in the case of 0 * inf + not-a-NaN because the IEEE spec
> entirely defines the behaviour there (you get the default
> NaN and Invalid is set), so that case is handled in the
> generic softfloat code. (The flag is called 'infzero'
> probably because in the calling code it indicates all
> the inf * zero cases, not just the info * zero + nan ones).
> 
> It's specifically the (0,inf,qnan) and (inf,0,qnan) cases
> where the spec allows the implementation to decide whether
> they raise Invalid or not (and what qnan to return if they
> do), so this is why we pass that flag through to the
> pick-a-NaN routine.
> 
> It looks like this part of the MIPS-specific code was
> incorrectly copied from the Arm implementation (which does
> return the default NaN here).
> 
> 
> As well as what the right NaN value should be, the other
> question for this function for the (0, inf, qnan) case is
> "should we raise Invalid?" -- what does the MIPS spec
> require here?
> 

Yes, MIPS docs say raising Invalid Operation is required,
and that has been confirmed by tests on hardware. No change
in code is needed regarding that. Mateja identified this piece
of information in his cover letter. A certain problem is that
MIPS FPU-related specs are a kind of scattered across
several docs and chapters within a doc.

Thank you for reminding!

Aleksandar

> thanks
> -- PMM



reply via email to

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