Date: Fri, 10 Mar 2017 10:54:29 -0800 From: Mark Millard <markmi@dsl-only.net> To: Konstantin Belousov <kostikbel@gmail.com> Cc: "freebsd-arm@freebsd.org" <freebsd-arm@freebsd.org> Subject: Re: Is CPUTYPE=cortex-A7 supposed to work? Message-ID: <0B79BDF3-4BAF-4164-8387-D47B795915F1@dsl-only.net> In-Reply-To: <20170310174444.GN16105@kib.kiev.ua> References: <871suc3nv8.fsf@news-spur.riddles.org.uk> <CANCZdfq4EwH%2B_9FVNai8s6Y-gdTjHJ8dNkJwSrnF%2BSAkdwvYdg@mail.gmail.com> <8737ely05c.fsf@news-spur.riddles.org.uk> <CANCZdfpftVHaPahTOP0vxB-FR%2BKtpqY9JMJr=F2DGifD0fhKMQ@mail.gmail.com> <87wpbxw3yd.fsf@news-spur.riddles.org.uk> <20170310174444.GN16105@kib.kiev.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2017-Mar-10, at 9:44 AM, Konstantin Belousov <kostikbel at gmail.com> = wrote: > On Fri, Mar 10, 2017 at 04:10:49PM +0000, Andrew Gierth wrote: >>>>>>> "Warner" =3D=3D Warner Losh <imp@bsdimp.com> writes: >>=20 >> Warner> I've not had good luck getting it to work. (cortex-a7 is the >> Warner> proper type name, btw). It kinda works, but ports are kinda >> Warner> wonky. >>=20 >>>> Well, I can now report that with a local fix for #217611 in place >>>> and everything recompiled for cortex-a7, I'm not seeing any >>>> wonkiness at all even with a lot of ports in use. >>=20 >> Warner> Awesome. What's the local fix? Is it in FreeBSD yet? >>=20 >> No, it's not in FreeBSD yet; I attached it as a patch to the bugzilla >> report: >>=20 >> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D217611 >> = https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D180669&action=3Ddiff= >>=20 >> My fix requires breaking the ABI, since the definition of mcontext_t >> simply does not have enough space to store all the registers, so I'm >> assuming it won't go into stable/11 (though that really needs _some_ >> kind of fix, since the bug can be demonstrated with ordinary >> floating-point code and no compile options). >>=20 >> It needs attention from someone with more kernel/arm experience than = I >> have to see whether I've missed something obvious (or subtle).=20 >>=20 >> (Maybe I should have filed it under "kern" rather than "arm"?) >=20 > When x86 AVX support was added, the very same problem existed: the x86 > mcontext_t has no space to store AVX registers, and worse, = architecture > explicitely allowed for future coprocessors to extend the register = file > further. In other words, even if breaking ABI and adding the storage > to mcontext_t for AVX once was decided, the solution would be not > sustainable. armv7 has a similar issue/status for floating point (and potentially for Integer-only NEON): = http://liris.cnrs.fr/~mmrissa/lib/exe/fetch.php?media=3Darmv7-a-r-manual.p= df says: > Appendix F Common VFP Subarchitecture Specification > Defines version 2 of the Common VFP Subarchitecture. > Note > This specification is not part of the ARM architecture specification. = This > sub-architectural information is included here as supplementary = information, > for the convenience of developers and users who might require this = information. > . . . > Appendix F Common VFP Subarchitecture Specification includes examples = of how > a Floating-point subarchitecture might define additional registers, in = the > SUBARCHITECTURE DEFINED register space using addresses in the 0b1001 = to 0b1111 > range. Appendix F is not part of the ARMv7 architecture. It is = included as an > example of how a Floating-point subarchitecture might be defined. > . . . [presuming a Common VFP Subarchitecture context:] > Floating-point support code > A complete Floating-point implementation might require a software = component, > called the support code. For example, if an implementation includes = VFPv3U or > VFPv4U, support code must handle the trapped floating-point = exceptions. The > interface to the support code is called the VFP subarchitecture. ARM = has > defined a subarchitecture that is suitable for use with = implementations of > the ARM Floating-point Extension, see Appendix F Common VFP = Subarchitecture > Specification. [FreeBSD does not currently have such support code as I understand.] > Context switch software can be written to always save and restore the > subarchitecture registers. In this case appropriate context switch = software > must be chosen based on the registers implemented "Subarchitectures" need not be ones defined by arm but arm does provide some examples that are commonly used. armv7 does not have registers for supporting floating point control and general operation directly in its architecture at all: it is a bigger distinction than just being optional. VFP versions are just the most common floating point addition alternatives as far as I can tell, not required ones. FreeBSD may need to identify what range of floating point support for armv6/armv7 it intends to cover up front since floating point is beyond-architecture (i.e., it is implementation-defined subarchitecture material). My be an ABI definition used implies more specifics than armv7 = architecture does of itself? That might cover the issue if the ABI in question was then referenced very explicitly. Another option would be an explicit list of -mcpu=3D options that imply certain things are present for sure. -march=3Darmv7-a does presume some optional things/extensions from the architecture are present if I understand right. It takes more compiler options to avoid those things. But covering the compiler presumptions for a list of -march=3D might by an alternative/addition. Non-floating-point-only NEON for armv7 would have a similar status as = far as I can tell. = http://infocenter.arm.com/help/topic/com.arm.doc.dht0002a/DHT0002A_introdu= cing_neon.pdf says: > There is no architectural requirement for a processor to implement = both VFP > and NEON, but the common features in the programmers models for these > extensions mean an operating system that supports VFP requires little = or no > modifications to also support NEON. It appears that "extensions" means "subarchitecture defined" and subarchitectures need not be defined by arm examples. There is also: = http://infocenter.arm.com/help/topic/com.arm.doc.ihi0053d/IHI0053D_acle_2_= 1.pdf which says: > __ARM_NEON is defined to a value indicating the Advanced SIMD (NEON) = architecture > supported. The only current value is 1. >=20 > In principle, for AArch32, the NEON architecture can exist in an = integer-only > version. To test for the presence of NEON floating-point vector = instructions, > test __ARM_NEON_FP. When NEON does occur in an integer-only version, = the VFP > scalar instruction set is also not present. Integer-only NEON hardware (or just lack of any use of floating-point = data types but use of Integer Neon when VFP is present) would also have the = signal handler issues as things are. And http://lists.llvm.org/pipermail/llvm-dev/2016-March/097613.html (2016-Mar-25) indicates that llvm/clang was intended to eventually have: > Examples: >=20 > Works today: > -mfpu=3Dsoft -> Int (ALU), FP (LIB), no VFP/NEON instructions > -mfpu=3Dsoftfp -> Int (ALU), FP (LIB), VFP/NEON instructions allowed > -mfpu=3Dvfp -> Int (ALU), FP (VFP) > -mfpu=3Dneon -> Int (NEON), FP (NEON) >=20 > Change proposed: > -mfpmath=3Dneon -mfpu=3Dvfp -> Int (ALU), FP (NEON) > -mfpmath=3Dvfp -mfpu=3Dneon -> Int (NEON), FP (VFP) =3D=3D=3D Mark Millard markmi at dsl-only.net
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?0B79BDF3-4BAF-4164-8387-D47B795915F1>