Epiphany - Alignment question (double word)

[Hesham Moustafa]

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.
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   );

&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

> 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
>