Epiphany - Alignment question (double word)

[Hesham Moustafa]

Hi,

On Tue, Nov 25, 2014 at 8:21 PM, Gedare Bloom <gedare at gwu.edu> wrote:

> I'm pretty sure STACK_ALIGNMENT just does the initial stack align for
> the start of the stack. The compiler is responsible for laying out the
> frames after that, and for generating aligned entries in the stack
> itself. Probably the compiler is being too lax. Check for some
> compiler flags for the target that might be used to increase the
> alignment, for example if there is a strict alignment flag. Check with
> the epiphany / parallela boards too, ask about compiler flags for
> alignment problems.
>
> I checked their GCC port, and I think they define the proper macros for
stack alignments to 8 bytes. However, when debugging on real HW
(Parallella), I can see that some structures are allocated on non 8-bytes
boundaries, and also structures passed as function arguments are not
aligned.

> -Gedare
>
> On Tue, Nov 25, 2014 at 2:06 PM, Hesham Moustafa
> <heshamelmatary at gmail.com> wrote:
> > Hi all,
> >
> > I came across an issue with alignment when I am porting RTEMS to Epiphany
> > now. The reference manual says that stores should be aligned according to
> > the store instruction type (half word, word, double word). For example
> strd
> > instruction should get an address aligned to 8 bytes. Although I set
> > CPU_ALIGNMENT and Stack aliment macros to 8 in cpu.h, I still get some
> > automatic variables not aligned to 8 bytes, which causes an exception
> when
> > executing relevant (double) store/load instructions.
> >
> > I had to apply a brute-force solution to get over this problem. For
> example
> > I add alignment's attribute to "CORE_mutex_Attributes attr __attribute__
> > ((aligned (8)));" and I set "#define CPU_TIMESTAMP_USE_STRUCT_TIMESPEC
> TRUE"
> > instead of using CPU_TIMESTAMP_USE_INT64
> >
> > Is there any other good solution for such a problem?
> >
> > Regards,
> > Hesham
> >
> > _______________________________________________
> > devel mailing list
> > devel at rtems.org
> > http://lists.rtems.org/mailman/listinfo/devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20141126/c72bc6a3/attachment-0002.html>