Re: [RFC PATCH v2] target/ppc: Enable hardfloat for PPC

From: Aleksandar Markovic <aleksandar.m.mail@gmail.com>
To: Programmingkid <programmingkidx@gmail.com>
Cc: "Alex Bennée" <alex.bennee@linaro.org>,
	"QEMU Developers" <qemu-devel@nongnu.org>,
	"qemu-ppc@nongnu.org" <qemu-ppc@nongnu.org>,
	"Howard Spoelstra" <hsp.cat7@gmail.com>,
	"luigi burdo" <intermediadc@hotmail.com>,
	"Dino Papararo" <skizzato73@msn.com>,
	"David Gibson" <david@gibson.dropbear.id.au>
Subject: Re: [RFC PATCH v2] target/ppc: Enable hardfloat for PPC
Date: Thu, 27 Feb 2020 08:16:58 +0100	[thread overview]
Message-ID: <CAL1e-=iK1NEOr=ZRBm9XtJw7Mn_23w1ra74e3yDGbfKPVTA9zw@mail.gmail.com> (raw)
In-Reply-To: <2126C4B4-B0F2-4B0F-ADEC-211466989E36@gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2735 bytes --]

On Thursday, February 27, 2020, Programmingkid <programmingkidx@gmail.com>
wrote:

>
> > On Feb 26, 2020, at 12:27 PM, Aleksandar Markovic <
> aleksandar.m.mail@gmail.com> wrote:
> >
> > On Wed, Feb 26, 2020 at 6:04 PM G 3 <programmingkidx@gmail.com> wrote:
> >>
> >> Accuracy is an important part of the IEEE 754 floating point standard.
> The whole purpose of this standard is to ensure floating point calculations
> are consistent across multiple CPUs. I believe referring to this patch as
> inaccurate is itself inaccurate. That gives the impression that this patch
> produces calculations that are not inline with established standards. This
> is not true. The only part of this patch that will produce incorrect values
> are the flags. There *may* be a program or two out there that depend on
> these flags, but for the majority of programs that only care about basic
> floating point arithmetic this patch will produce correct values. Currently
> the emulated PowerPC's FPU already produces wrong values for the flags.
> This patch does set the Inexact flag (which I don't like), but since I have
> never encountered any source code that cares for this flag, I can let it
> go. I think giving the user the ability to decide which option to use is
> the best thing to do.
> >>
> >
> > From the experiments described above, the patch in question changes the
> behavior
> > of applications (for example, sound is different with and without the
> > patch), which is
> > in contradiction with your claim that you "never encountered any
> > source code that
> > cares for this flag" and that "the only part of this patch that will
> > produce incorrect
> > values are the flags".
> >
> > In other words, and playing further with them:
> >
> > The claim that "referring to this patch as inaccurate is itself
> > inaccurate" is itself inaccurate.
> >
> > Best regards,
> > Aleksandar
>
> It is inaccurate to state that just because the USB audio device seems to
> play better with the hardfloat feature enabled that this changes the fact
> that I have yet to see any source code that actually reviews the flags. I
> have reviewed both the USB audio device and Apple's AppleUSBAudio class
> code and have not seen any mention of the exception flags.
>
>
I totally disagree with your using the term "hardfloat feature enabled" in
this context, speaking about this particulat patch. This may be just
wishful thinking. The right wording would be "hardfloat feature hacked", or
"hardfloat feature fooled".

The patch itself has the wrong, intentionally misleading and confusing
title from the outset. It should be something like  "target/ppc: Cheat
hardfloat feature into beleiving that inexact flag is always set"

Best regards,
Aleksabdar

[-- Attachment #2: Type: text/html, Size: 3361 bytes --]