Thread stack alignment requirements for ARM

[Michael Bergandi]

Hi all,

I am hoping that someone can share some knowledge on thread stack
alignment requirements for ARM targets and how eCos is handling it.

According to the ARM site, they say that stacks should be 16 byte
aligned. Then, they go on to say that there are a couple ways that
stack alignment requirement can be managed. One of which was if you
are running on an OS and the OS has taken steps to ensure the
requirement is met, then the application need not worry about it. I
don't think I fully understand what this means exactly.

Our particular target is the mx27 (ARM9). Out of habit, we make all
the memory for the thread stacks in our applications 4 byte aligned.
Is this enough? Is it really necessary?

I have found some packages in the kernel (specifically, bsd_tcpip)
that has thread stack memory allocated with no alignment attribute
set. This got me wondering how this all works.

I would love to here from someone with a much better grasp on this.

--
Mike

[Stanislav Meduna]

On 23.06.2011 04:37, Michael Bergandi wrote:

> According to the ARM site, they say that stacks should be 16 byte
> aligned. Then, they go on to say that there are a couple ways that
> stack alignment requirement can be managed. One of which was if you
> are running on an OS and the OS has taken steps to ensure the
> requirement is met, then the application need not worry about it. I
> don't think I fully understand what this means exactly.

HAL_THREAD_INIT_CONTEXT forces the alignment of the stack - see e.g.
 packages\hal\arm\arch\current\include\hal_arch.h:

register CYG_WORD _sp_ = ((CYG_WORD)_sparg_) &~15;


> Our particular target is the mx27 (ARM9). Out of habit, we make all
> the memory for the thread stacks in our applications 4 byte aligned.
> Is this enough? Is it really necessary?

Yes (but you are eventually wasting up to 12 bytes), no.

The linker script takes care of the sections and the
compiler and standard library (malloc) of the rest of the
alignment needs.

It only matters if you are building some kind of compiler/
linker/dynamic loader functionality or if you are upcasting
some datatypes (such as int * to double *) - I got burned
with this...

Regards
--
                                      Stano

[Nick Garnett-2]

On 23/06/11 03:37, Michael Bergandi wrote:

> Hi all,
>
> I am hoping that someone can share some knowledge on thread stack
> alignment requirements for ARM targets and how eCos is handling it.
>
> According to the ARM site, they say that stacks should be 16 byte
> aligned. Then, they go on to say that there are a couple ways that
> stack alignment requirement can be managed. One of which was if you
> are running on an OS and the OS has taken steps to ensure the
> requirement is met, then the application need not worry about it. I
> don't think I fully understand what this means exactly.
>
> Our particular target is the mx27 (ARM9). Out of habit, we make all
> the memory for the thread stacks in our applications 4 byte aligned.
> Is this enough? Is it really necessary?
>
> I have found some packages in the kernel (specifically, bsd_tcpip)
> that has thread stack memory allocated with no alignment attribute
> set. This got me wondering how this all works.
>
> I would love to here from someone with a much better grasp on this.
>

The alignment of the pieces of memory that are used as stacks does not
really matter. It is the alignment of the stack pointer that matters.
This is handled in HAL_THREAD_INIT_CONTEXT() which ensures that the
stack pointer is 16 byte aligned regardless of the alignment of the
stack pointer passed to it.


--
Nick Garnett                                       eCos Kernel Architect
eCosCentric Limited    http://www.eCosCentric.com       The eCos experts
Barnwell House, Barnwell Drive, Cambridge, UK.      Tel: [phone]
Registered in England and Wales:                         Reg No: 4422071

[Michael Bergandi]

Nick and Stano,

It's the stack _pointer_ that bears the requirement in which eCos
takes care of and not the stack memory allocation itself.

Fantastic! This all makes since.

Thank you guys. I appreciate the knowledge and your time.

--
Mike