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

[Cedric Blancher]

SPARCv7, SPARCv8 and SPARCv9 mandate natural alignment like all
'normal' RISC implementations. SPARCv9 ABI adds some 'special'
instructions (separate from the normal load/store instructions) for
unaligned access, but as said they come with costs, as stated before
PLUS the risk that they are unimplemented in the actual hardware and
trigger emulation traps.

Ced

On 27 May 2016 at 05:59, Mark Millard <markmi at dsl-only.net> wrote:
> On 2016-May-26, at 8:21 PM, Cedric Blancher <cedric.blancher at 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 <markmi at 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-sparc64 at freebsd.org mailing list
>>> https://lists.freebsd.org/mailman/listinfo/freebsd-sparc64
>>> To unsubscribe, send any mail to "freebsd-sparc64-unsubscribe at freebsd.org"
>>
>>
>>
>> --
>> Cedric Blancher <cedric.blancher at gmail.com>
>> Institute Pasteur
>
>
> ===
> Mark Millard
> markmi at dsl-only.net
>



-- 
Cedric Blancher <cedric.blancher at gmail.com>
Institute Pasteur