Date: Sat, 09 Sep 2017 14:34:10 -0600 From: Ian Lepore <ian@freebsd.org> To: Jan Beich <jbeich@FreeBSD.org>, Warner Losh <imp@bsdimp.com> Cc: "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: <1504989250.32063.66.camel@freebsd.org> In-Reply-To: <lgln-1xpu-wny@FreeBSD.org> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 2017-09-09 at 21:25 +0200, Jan Beich 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? > > > > > 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. We should fix that. In fact, we should probably fix it in exactly the way linux does it (does it today, I think it's their 3rd scheme so far), using getauxval() and elf AT_HWCAP. Adding the AT_HWCAP stuff would be relatively easy. I'm not as sure what to do about getauxval(). To be maximally linux-compatible (which would be good for ports) we'd put getauxval() in libc and make it work just like the linux one. That's a bit at odds with the support we have now, which is procstat_getauxv() in libprocstat. It's not very compatible with how linux getauxval() works, so using just that might lead to a lot of patches in ports. -- Ian > 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 > _______________________________________________
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1504989250.32063.66.camel>