Date: Sat, 9 Sep 2017 15:30:30 -0600 From: Warner Losh <imp@bsdimp.com> To: Ian Lepore <ian@freebsd.org> 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: <CANCZdfobKZG5XY7CZPubMpnf_1f7LuNZr-e7-rrNLL1NB6N=og@mail.gmail.com> In-Reply-To: <1504989250.32063.66.camel@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> <1504989250.32063.66.camel@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Sep 9, 2017 at 2:34 PM, Ian Lepore <ian@freebsd.org> wrote: > 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. > Ah, yes. We should do that. We need that for other reasons as well. It shouldn't be too hard, though I don't know where we get the AT_HWCAP from to start with. > 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. Totally agreed, even if it means breaking compatibility with the past. And as important as these issues are, they are orthogonal to armv7 :) Warner -- 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?CANCZdfobKZG5XY7CZPubMpnf_1f7LuNZr-e7-rrNLL1NB6N=og>