RISC-V double float alignment

[Chris Johns]

On 5/2/19 10:56 am, Joel Sherrill wrote:
> On Mon, Feb 4, 2019 at 5:07 PM Chris Johns <chrisj at rtems.org
> <mailto: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.

OK.

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

Yes I was hit by this architecture. I seem to remember something changed and
alignment on the stack changed.

>     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 was thinking of something in the testsuite that, as you say, looks 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.

I do not know.

Chris