linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: linux@arm.linux.org.uk (Russell King - ARM Linux)
To: linux-arm-kernel@lists.infradead.org
Subject: Removal of NWFPE in its entirety, and VFP emulation code
Date: Wed, 10 Apr 2013 21:03:44 +0100	[thread overview]
Message-ID: <20130410200344.GO14496@n2100.arm.linux.org.uk> (raw)
In-Reply-To: <yw1xehei8a19.fsf@unicorn.mansr.com>

On Wed, Apr 10, 2013 at 08:23:30PM +0100, M?ns Rullg?rd wrote:
> Russell King - ARM Linux <linux@arm.linux.org.uk> writes:
> 
> > On Wed, Apr 10, 2013 at 12:58:09PM +0100, M?ns Rullg?rd wrote:
> >> Russell King - ARM Linux <linux@arm.linux.org.uk> writes:
> >> 
> >> > On Wed, Apr 10, 2013 at 12:18:19PM +0100, M?ns Rullg?rd wrote:
> >> >> Russell King - ARM Linux <linux@arm.linux.org.uk> writes:
> >> >> 
> >> >> > The situation with VFP is likely less disruptive - only instructions
> >> >> > which aren't implemented in hardware (or, for example, if you ask for
> >> >> > inexact exceptions to be enabled) which are bounced to the software
> >> >> > support code will be affected.  I think OMAP should get away unscathed,
> >> >> > but ARM's implementation will bounce if inexact exceptions are enabled
> >> >> 
> >> >> What do you mean by this?  OMAP uses ARM's cores.
> >> >
> >> > OMAP's VFP reports that it never traps to support code for VFP instructions,
> >> > so the emulation code is never used on OMAP.
> >> 
> >> That is true for OMAP2 (ARM1136/VFP11) and OMAP3 (Cortex-A8).  OMAP4
> >> (Cortex-A9) and OMAP5 (Cortex-A15) both trap on vector operations.
> >
> > No.  Both OMAP3 and OMAP4 report that they are VFP subarchitecture 3,
> > and the VFP subarchitecture 3 never traps to support code for any
> > instruction (it's the "null subarchitecture" value.)
> 
> VFPv3 does not require hardware support for vector operations, and the
> Cortex-A9 NEON TRM [1] says this:
>
>    ARMv7 deprecates the use of VFP vector mode. The Cortex-A9 NEON MPE
>    hardware does not support VFP vector operations. [...] The Cortex-A9
>    NEON MPE provides high speed VFP operation without support code.
>    However, if an application requires VFP vector operation, then it
>    must use support code.
> 
> [1] http://infocenter.arm.com/help/topic/com.arm.doc.ddi0409i/CHDEEJDB.html
> 
> The VFP-only TRM [2] contains similar language:
> 
>   The use of VFP vector mode is deprecated in ARMv7.  Vector operations
>   are not supported in hardware.  If you use vectors, support code is
>   required.
> 
> [2] http://infocenter.arm.com/help/topic/com.arm.doc.ddi0408i/I1019986.html
> 
> The Cortex-A15 TRM [3] follows suit:
> 
>   Vector operations are not supported.  Any attempt to execute a vector
>   operation results in an Undefined Instruction exception.  If an
>   application requires VFP vector operation, then it must use VFP
>   support code.
> 
> [3] http://infocenter.arm.com/help/topic/com.arm.doc.ddi0438h/CEGCDBHC.html
> 
> In future, if you checked the relevant documentation before making bold
> claims, you might avoid making a fool of yourself.

Oh fuck off, just really fuck off you total dickface.  Really, do you
think that I, being the one who created the VFP support code, haven't
read the VFP documentation?  Christ, you are fucking thick.

Subarchitecture, bits [22:16]
0b0000011
VFP architecture v3 or later with Null subarchitecture. The entire floating-point
implementation is in hardware, and no software support code is required. The
VFP architecture version is indicated by the MVFR0 and MVFR1 registers.
This value can be used only by an implementation that does not support the trap
enable bits in the FPSCR, see Floating-point Status and Control Register
(FPSCR) on page A2-28.

And both OMAP3 and OMAP4 report *this* subarchitecture version.  Maybe
it's you who needs to take a reading lesson instead of making a prat of
*yourself*.

  reply	other threads:[~2013-04-10 20:03 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-04-10 10:40 Removal of NWFPE in its entirety, and VFP emulation code Russell King - ARM Linux
2013-04-10 11:18 ` Måns Rullgård
2013-04-10 11:42   ` Russell King - ARM Linux
2013-04-10 11:58     ` Måns Rullgård
2013-04-10 18:54       ` Russell King - ARM Linux
2013-04-10 19:23         ` Måns Rullgård
2013-04-10 20:03           ` Russell King - ARM Linux [this message]
2013-04-10 20:46             ` Måns Rullgård
2013-04-10 21:04               ` Russell King - ARM Linux
2013-04-10 21:18                 ` Måns Rullgård
2013-04-10 21:29                   ` Nicolas Pitre
2013-04-10 21:39                     ` Måns Rullgård
2013-04-10 21:45                   ` Russell King - ARM Linux
2013-04-10 22:21                     ` Måns Rullgård
2013-04-10 23:19                       ` Nicolas Pitre
2013-04-10 13:21 ` Will Deacon
2013-04-10 19:15   ` Russell King - ARM Linux
2013-04-10 17:30 ` Nicolas Pitre
2013-04-10 18:24   ` Steve McIntyre
2013-04-10 18:55   ` Russell King - ARM Linux
2013-04-10 18:58     ` Nicolas Pitre
2013-04-10 19:02       ` Russell King - ARM Linux
2013-04-11 18:37         ` Imre Kaloz
2013-04-10 19:00   ` Aaro Koskinen
2013-04-10 19:03     ` Nicolas Pitre
2013-04-10 19:06     ` Russell King - ARM Linux
2013-04-10 19:19       ` Nicolas Pitre
2013-04-10 19:25   ` Måns Rullgård
2013-04-10 20:04     ` Russell King - ARM Linux
2013-04-10 18:38 ` jonsmirl at gmail.com
2013-04-10 19:12   ` Russell King - ARM Linux
2013-04-10 21:46 ` Russell King - ARM Linux
2013-04-18 13:31 ` Russell King - ARM Linux

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20130410200344.GO14496@n2100.arm.linux.org.uk \
    --to=linux@arm.linux.org.uk \
    --cc=linux-arm-kernel@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).