[RTEMS Project] #2352: SPARC: Strange CPU_STACK_ALIGNMENT value

[RTEMS trac]

#2352: SPARC: Strange CPU_STACK_ALIGNMENT value
-----------------------------+---------------------
 Reporter:  sebastian.huber  |       Owner:  daniel
     Type:  defect           |      Status:  new
 Priority:  normal           |   Milestone:  4.11
Component:  General          |     Version:  4.11
 Severity:  normal           |  Resolution:
 Keywords:                   |
-----------------------------+---------------------
Description changed by sebastian.huber:

Old description:

> We have
>
> {{{
> /**
>  * CPU's worst alignment requirement for data types on a byte boundary.
> This
>  * alignment does not take into account the requirements for the stack.
>  *
>  * On the SPARC, this is required for double word loads and stores.
>  */
> #define CPU_ALIGNMENT      8
> }}}
>
> which is in line with the SPARC ABI.
>
> We have
>
> {{{
> /**
>  * This number corresponds to the byte alignment requirement for the
>  * stack.  This alignment requirement may be stricter than that for the
>  * data types alignment specified by CPU_ALIGNMENT.  If the CPU_ALIGNMENT
>  * is strict enough for the stack, then this should be set to 0.
>  *
>  * NOTE:  This must be a power of 2 either 0 or greater than
> CPU_ALIGNMENT.
>  *
>  * The alignment restrictions for the SPARC are not that strict but this
>  * should unsure that the stack is always sufficiently alignment that the
>  * window overflow, underflow, and flush routines can use double word
> loads
>  * and stores.
>  */
> #define CPU_STACK_ALIGNMENT        16
> }}}
>
> which makes not really sense in combination with
>
> {{{
> /** This defines the size of the ISF area for use in assembly. */
> #define CONTEXT_CONTROL_INTERRUPT_FRAME_SIZE \
>         CPU_MINIMUM_STACK_FRAME_SIZE + 0x50
> }}}
>
> (= not 16 byte aligned) and (_ISR_Handler)
>
> {{{
>         /*
>          *  Save the state of the interrupted task -- especially the
> global
>          *  registers -- in the Interrupt Stack Frame.  Note that the ISF
>          *  includes a regular minimum stack frame which will be used if
>          *  needed by register window overflow and underflow handlers.
>          *
>          *  REGISTERS SAME AS AT _ISR_Handler
>          */
>
>         sub     %fp, CONTEXT_CONTROL_INTERRUPT_FRAME_SIZE, %sp
>                                                ! make space for ISF
> }}}
>
> I suggest to change CPU_STACK_ALIGNMENT to
>
> {{{
> #define CPU_STACK_ALIGNMENT CPU_ALIGNMENT
> }}}

New description:

 We have

 {{{
 /**
  * CPU's worst alignment requirement for data types on a byte boundary.
 This
  * alignment does not take into account the requirements for the stack.
  *
  * On the SPARC, this is required for double word loads and stores.
  */
 #define CPU_ALIGNMENT      8
 }}}

 which is in line with the SPARC ABI.

 We have

 {{{
 /**
  * This number corresponds to the byte alignment requirement for the
  * stack.  This alignment requirement may be stricter than that for the
  * data types alignment specified by CPU_ALIGNMENT.  If the CPU_ALIGNMENT
  * is strict enough for the stack, then this should be set to 0.
  *
  * NOTE:  This must be a power of 2 either 0 or greater than
 CPU_ALIGNMENT.
  *
  * The alignment restrictions for the SPARC are not that strict but this
  * should unsure that the stack is always sufficiently alignment that the
  * window overflow, underflow, and flush routines can use double word
 loads
  * and stores.
  */
 #define CPU_STACK_ALIGNMENT        16
 }}}

 which makes not really sense since the compiler generates only 8 byte
 aligned frames, e.g. (200 % 16 == 8)
 {{{
 void f(char i)
 {
         volatile char j[123];
         j[122] = i;
 }
 }}}

 {{{
         .file   "test.c"
         .section        ".text"
         .align 4
         .global f
         .type   f, #function
         .proc   020
 f:
         add     %sp, -200, %sp
         stb     %o0, [%sp+194]
         jmp     %o7+8
          add    %sp, 200, %sp
         .size   f, .-f
         .ident  "GCC: (GNU) 4.9.3 20150519 (prerelease)"
 }}}

 I suggest to change CPU_STACK_ALIGNMENT to

 {{{
 #define CPU_STACK_ALIGNMENT CPU_ALIGNMENT
 }}}

--

--
Ticket URL: <http://devel.rtems.org/ticket/2352#comment:2>
RTEMS Project <http://www.rtems.org/>
RTEMS Project