On 5/2/19 10:56 am, Joel Sherrill wrote: > On Mon, Feb 4, 2019 at 5:07 PM Chris Johns <chr...@rtems.org > <mailto:chr...@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 _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
