Removal of NWFPE in its entirety, and VFP emulation code
Russell King - ARM Linux
linux at arm.linux.org.uk
Wed Apr 10 14:54:21 EDT 2013
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.)
These are the values reported by various platforms I have access to:
+ * Dove: VFP support v0.3: implementor 56 architecture 2 part 20 variant 9 rev 5
+ * OMAP4: VFP support v0.3: implementor 41 architecture 3 part 30 variant 9 rev 1
+ * OMAP3: VFP support v0.3: implementor 41 architecture 3 part 30 variant c rev 1
+ * Pi: VFP support v0.3: implementor 41 architecture 1 part 20 variant b rev 5
and "architecture" is actually the VFP subarchitecture number.
More information about the linux-arm-kernel
mailing list