[Top][All Lists]

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

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

From: Blue Swirl
Subject: Re: [Qemu-devel] [PATCH 0/5] target-arm: Implement UDIV/SDIV and fused multiply-accumulate
Date: Wed, 28 Sep 2011 19:13:15 +0000

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(-)

reply via email to

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