Date: Mon, 11 Sep 2017 15:40:50 -0400 From: Stephen Kiernan <hackagadget@gmail.com> To: Warner Losh <imp@bsdimp.com> Cc: Jan Beich <jbeich@freebsd.org>, "freebsd-arm@freebsd.org" <freebsd-arm@freebsd.org>, "freebsd-toolchain@FreeBSD.org" <freebsd-toolchain@freebsd.org>, Jan Beich <jbeich@vfemail.net> Subject: Re: FCP-100: armv7 plan Message-ID: <CAEm%2B2uXiOLQWX_h06TLYJTB%2BjcUR1ewmisrEDsd9JEfT0pUSFQ@mail.gmail.com> In-Reply-To: <CANCZdfpcmNK9cDfbY%2BEn9bu5QSuYWJxf8h091E73wugp2NFiGg@mail.gmail.com> References: <CANCZdfrCwdVOGWunSAjuxHzGcqhuH24iRQg63rvPFXXSmm-C6Q__2138.43810274756$1504912296$gmane$org@mail.gmail.com> <ingr-3d62-wny@FreeBSD.org> <CANCZdfondSykr1UM0CNTYpVr-6hzyROYn-C_jNC_%2BhO1r6SB2w@mail.gmail.com> <lgln-1xpu-wny@FreeBSD.org> <CANCZdfpcmNK9cDfbY%2BEn9bu5QSuYWJxf8h091E73wugp2NFiGg@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
(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@bsdimp.com> wrote: > On Sat, Sep 9, 2017 at 1:25 PM, Jan Beich <jbeich@freebsd.org> wrote: > > > Warner Losh <imp@bsdimp.com> writes: > > > > > On Sat, Sep 9, 2017 at 1:05 PM, Jan Beich <jbeich@vfemail.net> wrote: > > > > > >> Warner Losh <imp@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@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAEm%2B2uXiOLQWX_h06TLYJTB%2BjcUR1ewmisrEDsd9JEfT0pUSFQ>