(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 <[email protected]> wrote: > On Sat, Sep 9, 2017 at 1:25 PM, Jan Beich <[email protected]> wrote: > > > Warner Losh <[email protected]> writes: > > > > > On Sat, Sep 9, 2017 at 1:05 PM, Jan Beich <[email protected]> wrote: > > > > > >> Warner Losh <[email protected]> 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 > _______________________________________________ > [email protected] mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "[email protected]" > _______________________________________________ [email protected] mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "[email protected]"
