Re: FCP-100: armv7 plan
(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 wrote: > On Sat, Sep 9, 2017 at 1:25 PM, Jan Beich wrote: > > > Warner Losh writes: > > > > > On Sat, Sep 9, 2017 at 1:05 PM, Jan Beich wrote: > > > > > >> Warner Losh 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 - > 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-...@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscr...@freebsd.org" > ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: FCP-100: armv7 plan
On 9/9/17 3:25 PM, Jan Beich wrote: > Warner Losh writes: > >> On Sat, Sep 9, 2017 at 1:05 PM, Jan Beich wrote: >> >>> Warner Losh writes: >> 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. Do you > mean at compile time? If so then the following probably needs to change > > $ cc -target armv7-unknown-freebsd12.0-gnueabihf -dM -E - -i neon > #define __ARM_NEON 1 > #define __ARM_NEON_FP 0x4 > #define __ARM_NEON__ 1 Re: runtime, I have patches in review to add AT_HWCAP for native FreeBSD/arm binaries. Right now it doesn't support a NEON hwcap but it should be easy to add the flag using the same check to enable it that Linux does. -- John Baldwin ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Getauxval - was Re: FCP-100: armv7 plan
Apologies for the top post. Man pages indicate getauxval is a non standard glibc function. Is this an issue? Is there a more posix way I could compare against? I was previously wondering to myself if the Linux api is now more standard than the posix api? Looking forward to all opinions and comments. Rus Sent from my BlackBerry 10 smartphone on the Virgin Mobile network. Original Message From: Konstantin Belousov Sent: Saturday, September 9, 2017 2:46 PM To: Ian Lepore Cc: freebsd-...@freebsd.org; freebsd-toolchain@FreeBSD.org; Jan Beich; Jan Beich Subject: Re: FCP-100: armv7 plan On Sat, Sep 09, 2017 at 02:34:10PM -0600, Ian Lepore wrote: > 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. libprocstat is for accessing other processes information and address space. Our libc already has _elf_aux_info, but it is not exported. If you have a clear description of the desired API, I can add it (I do not want to read glibc code). ___ freebsd-...@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-arm To unsubscribe, send any mail to "freebsd-arm-unsubscr...@freebsd.org" ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: FCP-100: armv7 plan
On Sat, Sep 09, 2017 at 02:34:10PM -0600, Ian Lepore wrote: > 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. libprocstat is for accessing other processes information and address space. Our libc already has _elf_aux_info, but it is not exported. If you have a clear description of the desired API, I can add it (I do not want to read glibc code). ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: FCP-100: armv7 plan
On Sat, Sep 9, 2017 at 2:34 PM, Ian Lepore wrote: > On Sat, 2017-09-09 at 21:25 +0200, Jan Beich wrote: > > Warner Losh writes: > > > > > > > > On Sat, Sep 9, 2017 at 1:05 PM, Jan Beich > > > wrote: > > > > > > > > > > > Warner Losh 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 - > |& fgrep -i neon > > #define __ARM_NEON 1 > > #define __ARM_NEON_FP 0x4 > > #define __ARM_NEON__ 1 > > ___ > > ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: FCP-100: armv7 plan
On Sat, 2017-09-09 at 21:25 +0200, Jan Beich wrote: > Warner Losh writes: > > > > > On Sat, Sep 9, 2017 at 1:05 PM, Jan Beich > > wrote: > > > > > > > > Warner Losh 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 - |& fgrep -i neon > #define __ARM_NEON 1 > #define __ARM_NEON_FP 0x4 > #define __ARM_NEON__ 1 > ___ ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: FCP-100: armv7 plan
Warner, So you are saying NEON support is a compile time option that has no relevance to the Application Binary Interface, which is what the FCP-0100 was about? Thanks for clarification, Russ Sent from my BlackBerry 10 smartphone on the Virgin Mobile network. Original Message From: Warner Losh Sent: Saturday, September 9, 2017 12:37 PM To: Jan Beich Cc: freebsd-...@freebsd.org; freebsd-toolchain@FreeBSD.org; Jan Beich Subject: Re: FCP-100: armv7 plan On Sat, Sep 9, 2017 at 1:25 PM, Jan Beich wrote: > Warner Losh writes: > > > On Sat, Sep 9, 2017 at 1:05 PM, Jan Beich wrote: > > > >> Warner Losh 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 - 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-...@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-arm To unsubscribe, send any mail to "freebsd-arm-unsubscr...@freebsd.org" ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: FCP-100: armv7 plan
On Sat, Sep 9, 2017 at 1:25 PM, Jan Beich wrote: > Warner Losh writes: > > > On Sat, Sep 9, 2017 at 1:05 PM, Jan Beich wrote: > > > >> Warner Losh 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 - 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-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: FCP-100: armv7 plan
Warner Losh writes: > On Sat, Sep 9, 2017 at 1:05 PM, Jan Beich wrote: > >> Warner Losh 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. Do you mean at compile time? If so then the following probably needs to change $ cc -target armv7-unknown-freebsd12.0-gnueabihf -dM -E -https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: FCP-100: armv7 plan
On Sat, Sep 9, 2017 at 1:05 PM, Jan Beich wrote: > Warner Losh 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. 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. Warner ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: FCP-100: armv7 plan
Warner Losh 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 ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"