Re: [Qemu-devel] [PATCH 0/5] target-arm: Implement UDIV/SDIV and fused multiply-accumulate

[Blue Swirl]

On Wed, Sep 28, 2011 at 5:27 PM, Peter Maydell <address@hidden> wrote:
> This patch series implements support in QEMU for some (user-mode)
> instructions which are present on some recent processors
> (eg Cortex-A15).
>
> The new instructions are UDIV/SDIV (previously only available as a Thumb
> encoding for M-class cores, now an optional extension to ARMv7A), and
> the fused-multiply-accumulate instructions VFMA, VFMS, VFNMA, VFNMS.
> We don't (yet) support a specific processor for system mode with these
> extensions, so they are enabled only for ARM_CPUID_ANY.
>
> The most interesting part of this is the fused multiply-accumulate
> support which I have added to softfloat. Although this is only used
> by ARM at the moment I've put in some flags which should be sufficient
> for the variants provided by other architectures. (Specifically,
> x86, Itanium and SPARC64 VI all need the "negate product" flag
> since they have "-(a*b)+c" instructions. PPC needs the "negate
> result" and "negate addend" flags.)
>
> The NaN handling hooks are not as clean as the 2-operand versions.
> This is because there isn't really any consensus about what order
> the operands in a fused-mac should be in; ARM uses c+(a*b), PPC
> does something else, and so on. So even if there was more than
> one 3-operand IEEE operation a generic "pick one of 3 NaNs"
> function would be tricky; I opted to just be clear about the
> fact this was fused-mac specific. I've provided the PPC implementation
> of the NaN-selection function because the architecture manual was
> helpfully clear about what it was. x86 and SPARC don't seem to
> document the behaviour in this area :-(

SPARC64 VII Extensions says this:
"Also fnmadd and fnmsub behavior with rs1=NaN or rs2=NaN is different between
SPARC64 V and SPARC64 VII. SPARC64 VII outputs one of the NaN inputs
as it is, while
SPARC64 V outputs the one with the sign bit inverted."

> I've thrown in the "reinstate target-specific NaN handling" patch
> I posted earlier this week just to avoid possible patch conflicts.
>
> As usual, this has all been tested with a long run on my random
> instruction generation testbed.
>
>
> Peter Maydell (5):
>  softfloat: Reinstate accidentally disabled target-specific NaN
>    handling
>  target-arm: v6 media multiply space: UNDEF on unassigned encodings
>  target-arm: Add ARM UDIV/SDIV support
>  softfloat: Implement fused multiply-add
>  target-arm: Implement VFPv4 fused multiply-accumulate insns
>
>  fpu/softfloat-specialize.h |  178 ++++++++++++++++++
>  fpu/softfloat.c            |  433 
> ++++++++++++++++++++++++++++++++++++++++++++
>  fpu/softfloat.h            |   14 ++
>  target-arm/cpu.h           |    1 +
>  target-arm/helper.c        |   14 ++
>  target-arm/helper.h        |    3 +
>  target-arm/translate.c     |  115 +++++++++++-
>  7 files changed, 754 insertions(+), 4 deletions(-)
>
>
>