Epiphany - Alignment question (double word)

Gedare Bloom gedare at rtems.org
Wed Nov 26 18:47:36 UTC 2014


On Wed, Nov 26, 2014 at 12:06 PM, Hesham Moustafa
<heshamelmatary at gmail.com> wrote:
> On Wed, Nov 26, 2014 at 4:46 PM, Joel Sherrill
> <joel.sherrill at oarcorp.com> wrote:
>>
>>
>>
>> On November 26, 2014 10:34:16 AM CST, 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.
>>
>> So the stack is correctly aligned when the task is started but allocation of variables is misaligned? If so, that's a GCC bug.
>>
> Yes. I begin the stack at address 0x8EFFFFCC. Some issues with the
> mutex attribute before was solved with the attribute align statement.
Using align attribute is not a good long-term solution, so it is best
to resolve this problem now.

> For example the code below is not well generated
>
>  static void _Thread_Create_idle_for_cpu( Per_CPU_Control *cpu )
>      27 {
>      28   int i = 0;
>      29   Objects_Name    name;
>      30   Thread_Control *idle;
>      31
> ..
>  36    *  The entire workspace is zeroed during its initialization.  Thus, all
>      37    *  fields not explicitly assigned were explicitly zeroed by
>      38    *  _Workspace_Initialization.
>      39    */
>      40   idle = _Thread_Internal_allocate();
>      41
>      42   _Thread_Initialize(
>      43     &_Thread_Internal_information,
>      44     idle,
>      45     _Scheduler_Get_by_CPU( cpu ),
>      46     NULL,        /* allocate the stack */
>      47     _Stack_Ensure_minimum(
> rtems_configuration_get_idle_task_stack_size() ),
>      48     CPU_IDLE_TASK_IS_FP,
>      49     PRIORITY_MAXIMUM,
>      50     true,        /* preemptable */
>      51     THREAD_CPU_BUDGET_ALGORITHM_NONE,
>      52     NULL,        /* no budget algorithm callout */
>      53     0,           /* all interrupts enabled */
>      54     name
>      55   );
>
This is a good test case.

> &name is not multiple of 8, the problem happens with the last argument
> to _Thread_Initialize (name). It uses strd (store double) at which the
> program hangs. The store location MUST be double word aligned (which
> is not at run-time) although PARM_BOUNDARY is defined to 64 (bits) in
> epiphany.h at the GCC port
>
Since "name" is a stack variable, and the stack starts out aligned,
the problem seems to come from GCC's stack/frame handling.

>> If these are malloced, then it is an issue for the heap configuration for this port.
>>
>> >-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



More information about the devel mailing list