FCP-100: armv7 plan

[Stephen Kiernan]

(replying to all this time)

There are ARMv7 systems that do not have hardware floating point.

This is identified by being able to enable CP10 and/or CP11 in the ACR. If
one tries to enable them and, upon reading the ACR back, the values get
reset, then the hardware is not there.

I know this because the BCM56160 SoC from Broadcom does not have hardware
floating point and it is a Cortex-A9-based SoC.

On Sat, Sep 9, 2017 at 3:37 PM, Warner Losh <imp at bsdimp.com> wrote:

> On Sat, Sep 9, 2017 at 1:25 PM, Jan Beich <jbeich at freebsd.org> wrote:
>
> > Warner Losh <imp at bsdimp.com> writes:
> >
> > > On Sat, Sep 9, 2017 at 1:05 PM, Jan Beich <jbeich at vfemail.net> wrote:
> > >
> > >> Warner Losh <imp at bsdimp.com> writes:
> > >>
> > >> > Greetings,
> > >> >
> > >> > This will serve as 'Last Call' for any objections to the plan to
> > create
> > >> an
> > >> > armv7 MACHINE_ARCH in FreeBSD, as documented in FCP-0100.
> > >> [...]
> > >>
> > >> Some ports want NEON support but FCP-0100 is vague about
> > FreeBSD-specific
> > >> differences between armv6 and armv7. Clang appears to enable NEON for
> > all
> > >> *-gnueabi* targets but I have no clue about GCC. Apparently, Android
> and
> > >> Debian don't assume NEON on armv7.
> > >>
> > >> related: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221898
> > >>
> > >
> > > Yes. We are vague about it on purpose. Just like we're vague about MMX,
> > > MMX2, etc on x86 because different processors can/want use different
> > > things.
> >
> > Do you mean similar to how FreeBSD i386 is vague about not supporting
> > real i386, only i486 or later?
>
>
> I mean we don't enumerate the list of all the processor supported things.
> We default to compiling for a fairly middle of the road processor, but you
> can strip that back all the way to i486, or hyper optimize for the latest
> core-2 duo.
>
> However, armv6 vs armv7 can affect the ABI in subtle ways that's it's best
> to avoid by declaring the two different. One may be able to run armv6
> binaries on an armv7 CPUs still, but we're not specifically guaranteeing
> it.
>
> > The goal, if it doesn't work already, is for NEON to work if used,
> > > but not be required, just like all the other optional features of a
> CPU.
> >
> > FreeBSD doesn't support detecting NEON at runtime unlike Linux.
>
>
> No, I don't mean that at all.  I mean we don't care if it is enabled or
> not. It doesn't affect the ABI. The kernel knows about the extensions and
> saves the context when it's in use, just like the x86 kernel saves MMX, etc
> context when it's in use.
>
> Do you
> > mean at compile time? If so then the following probably needs to change
> >
> > $ cc -target armv7-unknown-freebsd12.0-gnueabihf -dM -E -</dev/null |&
> > fgrep -i neon
> > #define __ARM_NEON 1
> > #define __ARM_NEON_FP 0x4
> > #define __ARM_NEON__ 1
> >
>
> Right. that's based on the default target. gcc/clang can enable or disable
> it (and a dozen other things) depending on what options you give. We don't
> care. We'll run all binaries. It's up to the system integrator to mix/match
> the options so they get optimal performance for their platform.
>
> Just like on x86. If you compile for MMX and run it on 486 w/o run-time
> detection, you'll get a reserved instruction fault. Same philosophy here.
> We don't dictate policy for the binaries, just like on x86. However, most
> of them have run-time detection to be nicer to the users than a core dump,
> and most do the best thing for that CPU if they really care about
> performance, but those applications that don't can just do whatever and be
> fine.
>
> Warner
> _______________________________________________
> freebsd-arm at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-arm
> To unsubscribe, send any mail to "freebsd-arm-unsubscribe at freebsd.org"
>