[PATCH 1/3] score: Remove _Stack_Adjust_size()

[Joel Sherrill]

On 04/16/2012 10:24 AM, Sebastian Huber wrote:
> On 04/16/2012 05:11 PM, Gedare Bloom wrote:
>> On Mon, Apr 16, 2012 at 5:00 AM, Sebastian Huber
>> <sebastian.huber at embedded-brains.de>   wrote:
>>> On 04/15/2012 08:05 PM, Gedare Bloom wrote:
>>>> Where did the original stack size adjustment come from / what was its
>>>> motivation?
>>>
>>> The
>>>
>>> uint32_t _Stack_Adjust_size(size_t size)
>>> {
>>>    return size + CPU_STACK_ALIGNMENT;
>>> }
>>>
>>> is there since 1995-05-11 19:39:37.  It is probably there since the
>>> workspace allocator only aligns the memory by CPU_HEAP_ALIGNMENT.  The stack
>>> needs to be aligned by CPU_STACK_ALIGNMENT.  Thus if these values are
>>> arbitrary you have to adjust the allocated memory to fit as a stack.  You
>>> need to allocate at least CPU_STACK_ALIGNMENT - 1 additional bytes to do
>>> this.
>>>
>>>
>>>> Will this break something that was "fixed" by the
>>>> previous approach?
>>>
>>> I think this fixed a non-existing problem.  The CPU_HEAP_ALIGNMENT and
>>> CPU_STACK_ALIGNMENT are roughly the same on all supported architectures.
>>>    Also the requested stack size must be considerable larger than
>>> CPU_STACK_ALIGNMENT, otherwise you cannot call any functions.  Thus it is
>>> not a problem at all to align the memory.
>>>
>> The change seems reasonable (by sight) to me. The problem with
>> alignment changes is they can break in unpredictable ways :( But we'll
>> see if anyone ever complains I guess.
> The alignment does not change in any way.  In case you decrease all your stack
> sizes in your application by 8, then you have roughly the same effect as this
> change.
>
Obviously given that date, it is from the initial CVS import.

The intent was as you all describe -- you ask for N bytes and
the heap takes some overhead. Bump the request up so
you actually get what you asked for after accounting for that
factor and stack alignment fudge.

Whether this is currently needed is another matter.

-- 
Joel Sherrill, Ph.D.             Director of Research&   Development
joel.sherrill at OARcorp.com        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
     Support Available             (256) 722-9985