RISC-V double float alignment

[Joel Sherrill]

On Mon, Feb 4, 2019 at 5:07 PM Chris Johns <chrisj at rtems.org> wrote:

> On 2/2/19 6:53 am, Joel Sherrill wrote:
> > Then we should ensure proper alignment since we NEVER want an unaligned
> > exception on any architecture if it is avoidable. No point in taking the
> likely
> > performance hit or exception.
>
> Is this documented anywhere?
>

Unless it is in the porting guide, I doubt it. Alignment issues for
critical structures
and the stack is a porting issue.

I was just thinking of the m68k where it allowed unaligned accesses but
there
was often a hidden performance penalty.

>
> It is an important issue because a performance hit such as unaligned
> accesses
> silently happening is difficult to see and it tends to be accounted for as
> RTEMS
> not performing or hardware not performing. Is this something we could test
> for
> and check?
>

I don't know if it could be a static assertion but it could be a debug
check.
It could certainly be checked with a normal test which peeked under the
hood.

>
> I personally have never stopped and checked a BSP for correct alignment in
> all
> cases or the critical cases before using and when something exposes it I
> have
> been surprised.
>

Me too. We all assume that alignment was thought through by the person who
did the port. Similar to finding caching disabled on a BSP.

I suppose if we identify the critical structures that a test could check
them all.
But we should be careful about this. What is minimum needed and what is
for performance? 4 or 8 byte alignments would avoid faults/unaligned
accesses.
16 or 32 byte would be performance helps on many architectures for larger
structures.

--joel


>
> Chris
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20190204/4910f708/attachment.html>