10 Apr 2013 22:03
Re: Removal of NWFPE in its entirety, and VFP emulation code
Russell King - ARM Linux <linux <at> arm.linux.org.uk>
2013-04-10 20:03:44 GMT
2013-04-10 20:03:44 GMT
On Wed, Apr 10, 2013 at 08:23:30PM +0100, Måns Rullgård wrote: > Russell King - ARM Linux <linux <at> 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 <at> 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 <at> 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  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. > >  http://infocenter.arm.com/help/topic/com.arm.doc.ddi0409i/CHDEEJDB.html > > The VFP-only TRM  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. > >  http://infocenter.arm.com/help/topic/com.arm.doc.ddi0408i/I1019986.html > > The Cortex-A15 TRM  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. > >  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*.