Hi Alex,
maybe a pseudo code can show better what I mean 😊
if (ppc_fpu_instruction == USE_FPSCR) /* instruction have dot '.' so FPSCR will
be updated and we need have care about it */
soft_decode (ppc_fpu_instruction)
else /* instruction have not dot '.' and FPSCR will be never updated and we
don't need to have care about it -> maxspeed */
hard_decode (ppc_fpu_instruction)
In ppc assembly all instructions who needs to take care of inexact flag and/or
exception flags, are processed prior than test instructions, look at following
exception handling example:
fadd. f0,f1,f2 # f1 + f2 = f0. CR1 contains except.summary
bta 4,error # if bit 0 of CR1 is set, go to error
# bit 0 is set if any exception occurs
. # if clear, continue operation
.
.
error:
mcrfs 2,1 # copy FPSCR bits 4-7 to CR field 2
# now CR1 and CR2 (bits 6 through 10)
# contain all exception bits from FPSCR
bta 6,invalid # CR bit 6 signals invalid
bta 7,overflow # CR bit 7 signals overflow
bta 8,underflow # CR bit 8 signals underflow
bta 9,divbyzero # CR bit 9 signals divide-by-zero
bta 10,inexact # CR bit 10 signals inexact
invalid:
mcrfs 2,2 # copy FPSCR bits 8-11 to CR field 2
mcrfs 3,3 # copy FPSCR bits 12-15 to CR field 3
mcrfs 4,5 # copy FPSCR bits 20-23 to CR field 4
# invalid bits are now CR bits 11-16 and bit 23
# now do exception handling based on which invalid bit
# is set
overflow:
# do exception handling for overflow exception
underflow:
# do exception handling for underflow exception
divbyzero:
#do exception handling for the divide-by-zero exception
inexact:
# do exception handling for the inexact exception
In this way you can know as soon as possible if you can go with hardfloats or
not.
I leave to you TCG's experts how it works and how to implement it, I'm only
tryng to explain a possible fast way to go (if ever possible) 😊
..Large majority of software don't check for exceptions at all and if I really
want to pursue max precision I'll go for a software multiprecision library like
GMP or MPFR Libraries.
So the hardfloats 'should' be set as first choice and only if instruction
requires precision/error check process it in softfloats.
I hope to have added some new ideas to discussion, thank a lot Alex!
Dino
-----Messaggio originale-----
Da: Alex Bennée <alex.ben...@linaro.org>
Inviato: mercoledì 29 aprile 2020 13:57
A: Dino Papararo <skizzat...@msn.com>
Cc: luoyongg...@gmail.com; BALATON Zoltan <bala...@eik.bme.hu>; Mark
Cave-Ayland <mark.cave-ayl...@ilande.co.uk>; Programmingkid
<programmingk...@gmail.com>; Howard Spoelstra <hsp.c...@gmail.com>;
qemu-...@nongnu.org; qemu-devel@nongnu.org
Oggetto: Re: R: About hardfloat in ppc
Dino Papararo <skizzat...@msn.com> writes:
> Hello,
> about handling of PPC fpu exceptions and Hard Floats support we could
> consider a different approach for different instructions.
> i.e. not all fpu instructions take care about inexact or exceptions bits: if
> I take a simple fadd f0,f1,f2 I'll copy value derived from adding f1+f2 into
> f1 register and no one will check about inexact or exception bits raised into
> FPSCR register.
> Instead if I'll take fadd. f0,f1,f2 the dot following the add instructions
> means I want take inexact or exceptions bits into account.
> So I could use hard floats for first case and softfloats for second case.
> Could this be a fast solution to start implement hard floats for PPC??
While it may be true that normal software practice is not to read the exception
registers for every operation we can't base our emulation on that. We must
always be able to re-create the state of the exception registers whenever they
may be read by the program. There are 3 cases this may happen:
- a direct read of the inexact register
- checking the sigcontext of a synchronous exception (e.g. fault)
- checking the sigcontext of an asynchronous exception (e.g. timer/IPI)
Given the way the translator works we can simplify the asynchronous case
because we know they are only ever delivered at the start of translated blocks.
We must have a fully rectified system state at the end of every block. So lets
consider some cases:
fpOpA
clear flags
fpOpB
clear flags
fpOpC
read flags
Assuming we know the fpOps can't generate exceptions we can know that only
fpOpC will ever generate a user visible floating point flags so we can indeed
use hardfloat for fpOpA and fpOpB. However if we see the
pattern:
fpOpA
ld/st
clear flags
fpOpB
read flags
we must have the fully rectified version of the flags because the ld/st may
fault. However it's not guaranteed it will fault so we could defer the flag
calculation for fpOpA until such time as we need it. The easiest way would be
to save the values going into the operation and then re-run it in softfloat
when required (hopefully never ;-).
A lot will depend on the behaviour of the architecture. For example:
fpOpA
fpOpB
read flags
whether or not we need to be able to calculate the flags for fpOpA will depend
on if fpOpB completely resets the flags visible or if the result is additive.
So in short I think there may be scope for using hardfloat but it will require
knowledge of front-end knowing if it is safe to skip flag calculation in
particular cases. We might even need support within TCG for saving (and
marking) temporaries over potentially faulting boundaries so these lazy
evaluations can be done. We can certainly add a fp-status less set of
primitives to softfloat which can use the hardfloat path when we know we are
using normal numbers.
>
> A little of documentation here:
> http://mirror.informatimago.com/next/developer.apple.com/documentation
> /mac/PPCNumerics/PPCNumerics-154.html
>
> Regards,
> Dino Papararo
>
> -----Messaggio originale-----
> Da: Qemu-devel <qemu-devel-bounces+skizzato73=msn....@nongnu.org> Per
> conto di Alex Bennée
> Inviato: martedì 28 aprile 2020 10:37
> A: luoyongg...@gmail.com
> Cc: qemu-...@nongnu.org; qemu-devel@nongnu.org
> Oggetto: Re: About hardfloat in ppc
>
>
> 罗勇刚(Yonggang Luo) <luoyongg...@gmail.com> writes:
>
>> I am confusing why only inexact are set then we can use hard-float.
>
> The inexact behaviour of the host hardware may be different from the guest
> architecture we are trying to emulate and the host hardware may not be
> configurable to emulate the guest mode.
>
> Have a look in softfloat.c and see all the places where float_flag_inexact is
> set. Can you convince yourself that the host hardware will do the same?
>
>> And PPC always clearing inexact flag before calling to soft-float
>> funcitons. so we can not optimize it with hard-float.
>> I need some resouces about ineact flag and why always clearing
>> inexcat in PPC FP simualtion.
>
> Because that is the behaviour of the PPC floating point unit. The inexact
> flag will represent the last operation done.
>
>> I am looking for two possible solution:
>> 1. do not clear inexact flag in PPC simulation 2. even the inexact
>> are cleared, we can still use alternative hard-float.
>>
>> But now I am the beginner, Have no clue about all the things.
>
> Well you'll need to learn about floating point because these are rather
> fundamental aspects of it's behaviour. In the old days QEMU used to use the
> host floating point processor with it's template based translation.
> However this led to lots of weird bugs because the floating point answers
> under qemu where different from the target it was trying to emulate. It was
> for this reason softfloat was introduced. The hardfloat optimisation can only
> be done when we are confident that we will get the exact same answer of the
> target we are trying to emulate - a "faster but incorrect" mode is just going
> to cause confusion as discussed in the previous thread. Have you read that
> yet?
>
>>
>> On Mon, Apr 27, 2020 at 7:10 PM Alex Bennée <alex.ben...@linaro.org> wrote:
>>
>>>
>>> BALATON Zoltan <bala...@eik.bme.hu> writes:
>>>
>>> > On Mon, 27 Apr 2020, Alex Bennée wrote:
>>> >> 罗勇刚(Yonggang Luo) <luoyongg...@gmail.com> writes:
>>> >>> Because ppc fpu-helper are always clearing float_flag_inexact,
>>> >>> So is that possible to optimize the performance when
>>> float_flag_inexact
>>> >>> are cleared?
>>> >>
>>> >> There was some discussion about this in the last thread about
>>> >> enabling hardfloat for PPC. See the thread:
>>> >>
>>> >> Subject: [RFC PATCH v2] target/ppc: Enable hardfloat for PPC
>>> >> Date: Tue, 18 Feb 2020 18:10:16 +0100
>>> >> Message-Id: <20200218171702.979f0746...@zero.eik.bme.hu>
>>> >
>>> > I've answered this already with link to that thread here:
>>> >
>>> > On Fri, 10 Apr 2020, BALATON Zoltan wrote:
>>> > : Date: Fri, 10 Apr 2020 20:04:53 +0200 (CEST)
>>> > : From: BALATON Zoltan <bala...@eik.bme.hu>
>>> > : To: "罗勇刚(Yonggang Luo)" <luoyongg...@gmail.com>
>>> > : Cc: qemu-devel@nongnu.org, Mark Cave-Ayland, John Arbuckle,
>>> qemu-...@nongnu.org, Paul Clarke, Howard Spoelstra, David Gibson
>>> > : Subject: Re: [RFC PATCH v2] target/ppc: Enable hardfloat for PPC
>>> > :
>>> > : On Fri, 10 Apr 2020, 罗勇刚(Yonggang Luo) wrote:
>>> > :> Are this stable now? I'd like to see hard float to be landed:)
>>> > :
>>> > : If you want to see hardfloat for PPC then you should read the
>>> > replies to : this patch which can be found here:
>>> > :
>>> > : http://patchwork.ozlabs.org/patch/1240235/
>>> > :
>>> > : to understand what's needed then try to implement the solution
>>> > with FP : exceptions cached in a global that maybe could work. I
>>> > won't be able to : do that as said here:
>>> > :
>>> > :
>>> > https://lists.nongnu.org/archive/html/qemu-ppc/2020-03/msg00006.ht
>>> > m
>>> > l
>>> > :
>>> > : because I don't have time to learn all the details needed. I think :
>>> > others are in the same situation so unless somebody puts in the :
>>> > necessary effort this won't change.
>>> >
>>> > Which also had a proposed solution to the problem that you could
>>> > try to implement, in particular see this message:
>>> >
>>> >
>>> http://patchwork.ozlabs.org/project/qemu-devel/patch/20200218171702.
>>> 9
>>> 79f0746...@zero.eik.bme.hu/#2375124
>>> >
>>> > amd Richard's reply immediately below that. In short to optimise
>>> > FPU emulation we would either find a way to compute inexact flag
>>> > quickly without reading the FPU status (this may not be possible)
>>> > or somehow get status from the FPU but the obvious way of claring
>>> > the flag and reading them after each operation is too slow. So
>>> > maybe using exceptions and only clearing when actually there's a
>>> > change could be faster.
>>> >
>>> > As to how to use exceptions see this message in above thread:
>>> >
>>> > https://lists.nongnu.org/archive/html/qemu-ppc/2020-03/msg00005.ht
>>> > m
>>> > l
>>> >
>>> > But that's only to show how to hook in an exception handler what
>>> > it does needs to be implemented. Then tested and benchmarked.
>>> >
>>> > I still don't know where are the extensive PPC floating point
>>> > tests to use for checking results though as that was never answered.
>>>
>>> Specifically for PPC we don't have them. We use the softfloat test
>>> cases to exercise our softfloat/hardfloat code as part of "make
>>> check-softfloat". You can also re-build fp-bench for each guest
>>> target to measure raw throughput.
>>>
>>> >> However in short the problem is if the float_flag_inexact is
>>> >> clear you must use softfloat so you can properly calculate the
>>> >> inexact status. We can't take advantage of the inexact stickiness
>>> >> without loosing the fidelity of the calculation.
>>> >
>>> > I still don't get why can't we use hardware via exception handler
>>> > to detect flags for us and why do we only use hardfloat in some
>>> > corner cases. If reading the status is too costly then we could
>>> > mirror it in a global which is set by an FP exception handler.
>>> > Shouldn't that be faster? Is there a reason that can't work?
>>>
>>> It would work but it would be slow. Almost every FP operation sets
>>> the inexact flag so it would generate an exception and exceptions
>>> take time to process.
>>>
>>> For the guests where we use hardfloat operations with inexact
>>> already latched is not a corner case - it is the common case which
>>> is why it helps.
>>>
>>> >
>>> > Regards,
>>> > BALATON Zoltan
>>>
>>>
>>> --
>>> Alex Bennée
>>>
--
Alex Bennée
