Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 27 May 2016 06:14:54 +0200
From:      Cedric Blancher <cedric.blancher@gmail.com>
To:        Mark Millard <markmi@dsl-only.net>
Cc:        freebsd-sparc64@freebsd.org, freebsd-arm <freebsd-arm@freebsd.org>,  FreeBSD Toolchain <freebsd-toolchain@freebsd.org>, mandree@freebsd.org
Subject:   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]
Message-ID:  <CALXu0Uc2Ssqs5OzCpTZs0Mcy4Y0ZQBzKAJPpT1LjnMoD-8updg@mail.gmail.com>
In-Reply-To: <F79AE83A-B973-4FA1-BC6C-18FC24F6C41F@dsl-only.net>
References:  <7AFD3661-9764-434B-A387-FD31B62DD77E@dsl-only.net> <CALXu0Uer=nOKBvd8x%2Bf=7F36603LRpkarAY4QOqau-4n_sLqQw@mail.gmail.com> <F79AE83A-B973-4FA1-BC6C-18FC24F6C41F@dsl-only.net>

next in thread | previous in thread | raw e-mail | index | archive | help
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@dsl-only.net> wrote:
> On 2016-May-26, at 8:21 PM, Cedric Blancher <cedric.blancher@gmail.com> w=
rote:
>
>> 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 f=
or many years, working on the software tools that were used for that subjec=
t 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 re=
port originally for armv7-a/cortex-a7 as FreeBSD formerly configured things=
 instead also likely applies to some SPARC variation/configuration that Fre=
eBSD supports. (See later below.)
>
> If FreeBSD has some other fairly strict alignment context that is not a S=
PARC that might also serve.
>
> Unless upstream can be told that some specific FreeBSD variant is unsuppo=
rted by their software because of presuming unaligned access is okay, I dou=
bt 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@dsl-only.net> wrote:
>>> Is is safe to interpret that an rpi2 armv7/cortex-a7 unaligned access f=
ailure [from before -r300694] would (likely?) also be a failure on some for=
ms 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=3D207096 ). I'd rec=
ently commented that the report might go away after testing what is now -r3=
00694 (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 ob=
serve, if nothing else than to validate at least some of my understanding t=
hat 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 f=
or SPARCs. Nor am I familiar with the choices FreeBSD may have made for SPA=
RC configuration coverage.
>>>
>>> As a matter of hear-say my impression is that some SPARCs can be config=
ured 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 leas=
t 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 b=
ecause 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.
>>>
>>> =3D=3D=3D
>>> Mark Millard
>>> markmi at dsl-only.net
>>>
>>> _______________________________________________
>>> freebsd-sparc64@freebsd.org mailing list
>>> https://lists.freebsd.org/mailman/listinfo/freebsd-sparc64
>>> To unsubscribe, send any mail to "freebsd-sparc64-unsubscribe@freebsd.o=
rg"
>>
>>
>>
>> --
>> Cedric Blancher <cedric.blancher@gmail.com>
>> Institute Pasteur
>
>
> =3D=3D=3D
> Mark Millard
> markmi at dsl-only.net
>



--=20
Cedric Blancher <cedric.blancher@gmail.com>
Institute Pasteur



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CALXu0Uc2Ssqs5OzCpTZs0Mcy4Y0ZQBzKAJPpT1LjnMoD-8updg>