On 2016-May-26, at 8:21 PM, Cedric Blancher <cedric.blanc...@gmail.com> wrote:
> All pure RISC implementations enforce 'natural alignment' - a 32bit > data type must be aligned 32bit, i.e. 4 bytes, a 64bit data type must > be 8 byte aligned, a 128bit data type must be 16 byte aligned. > Some RISC implementations are not pure, but still the misalignment > comes with a (performance) penalty, either by issuing two loads or > running through a whole trap handler (!!!!) function with hundreds of > instructions. > > Ced Thanks for the notes. Having once worked in a "micros" group in a logic analyzer product line for many years, working on the software tools that were used for that subject area, I'm very familiar with that general structure of alternatives --but not with SPARC specifics. In your terminology: I've no clue how pure of a RISC implementation is involved for any SPARC variation. I'm looking for SPARC-specific information that suggests if the defect report originally for armv7-a/cortex-a7 as FreeBSD formerly configured things instead also likely applies to some SPARC variation/configuration that FreeBSD supports. (See later below.) If FreeBSD has some other fairly strict alignment context that is not a SPARC that might also serve. Unless upstream can be told that some specific FreeBSD variant is unsupported by their software because of presuming unaligned access is okay, I doubt that a report to upstream should be made based on FreeBSD as a context. (This presumes that the port passes a test under the new armv7-a/cortex-a7 and related alignment requirements. I'm not to that point yet.) > On 27 May 2016 at 00:03, Mark Millard <mar...@dsl-only.net> wrote: >> Is is safe to interpret that an rpi2 armv7/cortex-a7 unaligned access >> failure [from before -r300694] would (likely?) also be a failure on some >> forms of FreeBSD SPARC use? >> >> >> Why I ask: >> >> One of the ports that I had submitted a bug report for unaligned access >> problems on a rpi2 (armv7-a/cortex-a7 style handling) was: >> >> archivers/lzo2 >> >> ( https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207096 ). I'd recently >> commented that the report might go away after testing what is now -r300694 >> (allowing more unaligned access on, for example, armv7-a/cortex-a7). >> >> Matthias Andree has since asked in a comment: >> >>> ISTR SPARC architectures also barf on unaligned access, so is it worth >>> bothering the upstream author? >> >> I have generally stuck to architectures for which I have examples to >> observe, if nothing else than to validate at least some of my understanding >> that is from reading materials. I normally only submit what I've observed in >> some form. >> >> I've no such SPARC context nor do I have knowledge/reference material for >> SPARCs. Nor am I familiar with the choices FreeBSD may have made for SPARC >> configuration coverage. >> >> As a matter of hear-say my impression is that some SPARCs can be configured >> to require some variation of strict alignment. >> >> But I do not know how much I can infer from what I observed on a rpi2 >> (armv7-a/cortex-a7) to FreeBSD SPARC use getting similar results for at >> least come configurations. Nor do I have access to a test environment for >> SPARC. >> >> So I wonder if my archivers/lzo2 submittal in question should survive >> because of SPARC even if the problem is validated to go away for the updated >> rpi2 like contexts (with armv7-a/cortex-a7 tailoring possibly involved). I >> have some other submittals that might face the same type of question. >> >> === >> Mark Millard >> markmi at dsl-only.net >> >> _______________________________________________ >> freebsd-spar...@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-sparc64 >> To unsubscribe, send any mail to "freebsd-sparc64-unsubscr...@freebsd.org" > > > > -- > Cedric Blancher <cedric.blanc...@gmail.com> > Institute Pasteur === Mark Millard markmi at dsl-only.net _______________________________________________ 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"
