Re: [ECOS] HAL_THREAD_INIT_CONTEXT

[Sergei Organov <osv at javad dot ru>]

And as far as I remember, TMS320C3/4x also have stack that grows upward, so
there are at least 2 such processors that are supported by GCC. The problem
with such processors could be solved by allowing HAL to define STACK_GROWS_UP
macro that will be used then by the kernel to decide which end of the stack
area to pass to the HAL as the stack base though.

As for FP support, while the issue with the interface is not resolved, I've
decided to allocate space for FP context on the bottom of stack. For PPC it
means all threads (even those that never use FP) need to have additional ~300
bytes of stack. I'd like to have some graceful solution to the problem in the
future though.

My suggestion is to add 'stack_size' parameter to the HAL_THREAD_INIT_CONTEXT
as soon as possible. The later it will be done the more HALs will require to
be changed. Two good things about such a change are that it doesn't break HALs
silently and changing a HAL to the new interface is trivial. Anyway, it should 
bring less troubles to HAL developers than, for example, switch to the CDL
based configuration brought, I believe.

Alternatively, the documentation for the HAL_THREAD_INIT_CONTEXT could be
changed to guarantee that the second parameter is the pointer to the
Cyg_Thread object, and that the macro will be invoked only from within
Cyg_Thread member or friend function. The latter is required for 'stack_size'
member to be accessible within the macro. This allows to keep HALs unchanged
but invalidates the "context" test that should be either removed or
reimplemented. I don't believe this is the right solution though because it
makes HAL too dependent on the kernel and its internals.

Sergei.

Ian Lance Taylor <ian@zembu.com> writes:
>    From: Nick Garnett <nickg@cygnus.co.uk>
>    Date: 19 Apr 2000 19:10:17 +0100
> 
>    At present GCC does not support any rising-stack processors.
> 
> The stack grows upward on the i960, among others.
> 
> Perhaps you meant that eCos does not support any rising-stack
> processors.
> 
> Ian