Epiphany - Alignment question (double word)

[Gedare Bloom]

Smells like a compiler-toolchain problem to me. -Gedare

On Wed, Nov 26, 2014 at 11:34 AM, Hesham Moustafa
<heshamelmatary at gmail.com> wrote:
> 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
>
>
>
> _______________________________________________
> devel mailing list
> devel at rtems.org
> http://lists.rtems.org/mailman/listinfo/devel