Re: R: About hardfloat in ppc

[Peter Maydell]

On Wed, 29 Apr 2020 at 15:33, Dino Papararo <address@hidden> wrote:
>
> 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)

My understanding was that the '.' indicates whether
the instruction updates CR1 (the condition register),
which is separate from whether it updates FPSCR
flags. So all insns update FPSCR flags; insns with
a '.' additionally update CR state which can be
tested by a following branch insn. (I'm not a PPC
expert but that's what my reading of the ISA spec is.)

> 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

This may be a common pattern, but the architecture doesn't
require it. You could equally do

    fadd f0,f1,f2   # insn which sets fpscr bits
    mffs 30         # copy whole fpscr to a gp register
    # now do stuff based on that value

So unless you can tell for certain that nothing in
the future guest execution can the relevant FPSCR bits
before they're overwritten, you have to generate them
correctly; or be able to re-generate them later, if
you want to get fancy (you could imagine a scheme
similar to how we handle CPU condition flags on
some guests, where instead of calculating them every
time we make a note of what the operation that should
have set them was, so that at the point where the
guest actually does read the fpscr or do something
else that demands the real flag value we can recreate
them, in this case by repeating the fp operation via
softfloat. Getting that working would be a non-trivial
project, though.)

thanks
-- PMM