Date: Tue, 24 May 2016 16:55:48 -0600 From: Ian Lepore <ian@freebsd.org> To: Mark Millard <markmi@dsl-only.net> Cc: freebsd-arm <freebsd-arm@freebsd.org> Subject: Re: xorg broken on Beaglebone black revision 300438 Message-ID: <1464130548.1204.25.camel@freebsd.org> In-Reply-To: <E268D55F-7E4D-4FF7-B38E-0912F275BF0C@dsl-only.net> References: <AE62E2F1-1D9F-418F-97E8-6D7F0E6B4B87@dsl-only.net> <1464127156.1204.10.camel@freebsd.org> <E268D55F-7E4D-4FF7-B38E-0912F275BF0C@dsl-only.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 2016-05-24 at 15:19 -0700, Mark Millard wrote: > On 2016-May-24, at 2:59 PM, Ian Lepore <ian at freebsd.org> wrote: > > > On Tue, 2016-05-24 at 14:35 -0700, Mark Millard wrote: > > > Quoting from Otacílio Tue May 24 00:06:10 UTC 2016 and its locore > > > -v6.S changes: > > > > > > > - orr r7, #CPU_CONTROL_UNAL_ENABLE > > > > - orr r7, #CPU_CONTROL_AFLT_ENABLE > > > > + bic r7, #CPU_CONTROL_UNAL_ENABLE > > > > + bic r7, #CPU_CONTROL_AFLT_ENABLE > > > > > > -r295256 (2016-Feb-14) changed from: > > > > > > bic r7, #CPU_CONTROL_UNAL_ENABLE > > > > > > to: > > > > > > orr r7, #CPU_CONTROL_UNAL_ENABLE > > > > > > in two places (moving it a few lines down for each example as > > > well). > > > So this much of the proposed changes would be reverting the > > > -r295256 > > > change. The check in comment indicates the bit is RAO/SBOP for > > > armv7. > > > For armv6 the check in comment claims it controls armv5 > > > compatible > > > alignment support. > > > > > > But: > > > > > > orr r7, #CPU_CONTROL_AFLT_ENABLE > > > > > > has been in locore-v6.S since the file's first checkin. So this > > > change to bic here be new. > > > > > > What is the FreeBSD intent for each of the two new settings for > > > armv7? armv6? > > > > > > > It was always wrong to clear CPU_CONTROL_UNAL_ENABLE on armv7 (it's > > documented as RAO/SBOP). Setting it on armv6 makes the v6 (which > > is > > only the RPi in our world) behave the same as v7. So that change > > was > > just a bugfix. > > > > I think FreeBSD is the only major OS left that is enforcing strict > > alignment on armv6/v7 and it causes a lot of trouble for ports and > > other 3rd party software, and prevents us from enabling certain > > compiler options and optimizations. I'm very close to a commit to > > stop > > enforcing strict alignment (clear rather than > > CPU_CONTROL_AFLT_ENABLE). > > I've been testing it yesterday and today, and haven't run into any > > trouble at all. > > > > -- Ian > > Good to know. I had submitted at least one port bug report that will > likely need to be canceled if this goes through. Effectively its an > ABI change allowing a wider variety of code to be compliant. > It was partly all that testing you did a few months ago, and the PRs and discussions coming out of that, which are driving these changes. If I could get away with procrastinating a bit more, I probably would (always too busy), but with the big hardfloat abi change and with a code freeze coming up later this week, this seems like the last chance to do some disruptive changes that are long overdue. > Is the kernel involved in emulating access/instructions via some > technique for misaligned access for armv6/armv7 for some types of > instructions? Are there performance issues/tradeoffs that might > contribute to sometimes choosing to be careful about alignment? > Nope, no emulation, the hardware is able to do this, we've just always run with alignment faults enabled, partly because base freebsd already has to work on other strict-alignment hardware anyway. The driver of this change is ports more than anything -- increasingly you run into code that assumes #ifdef __arm__ is sufficient to mean "unaligned access will work". There are a few arm instructions that still require alignment, but (at least in theory) the compiler knows about that and only emits those instructions when it knows they're safe (such as it knowing that the stack stays aligned to 8-byte boundaries in non-leaf functions). We'll see; everything seems okay in testing I've done so far. Performance-wise, there is a cost for unaligned access. The hardware has to do more work so unaligned accesses take extra cycles. On the other hand, if the data is unaligned, you also have to use extra cycles, potentially a lot of them, to copy-align the data or access it a byte at a time and reassmble it in a register. In theory this should be faster than doing copy-align stuff. -- Ian > In one way I liked the strict alignment environment being around: It > allowed easily testing if software was more portable for such issues > vs. not. (Not that FreeBSD should use such criteria for its choices.) >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1464130548.1204.25.camel>