Re: Are there SPARC [or other] aligned memory access requirements to avoid exceptions? [now that 11.0's armv6/v7 is allowing more unaligned accesses]

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

On 27 May 2016 at 00:03, Mark Millard <[email protected]> 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
>
> _______________________________________________
> [email protected] mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-sparc64
> To unsubscribe, send any mail to "[email protected]"



-- 
Cedric Blancher <[email protected]>
Institute Pasteur
_______________________________________________
[email protected] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arm
To unsubscribe, send any mail to "[email protected]"