generalise the stack checking functions

friedl wrote on Saturday, February 09, 2013:

Hi Richard!

I’ve just posted the patch

generalise the stack checking functions on the Feature Requests tracker.

This patch enables ports of FreeRTOS to architectures which use/need more than
one stack.

To support the stack overflow checking functionality on such a port for the
additional stack(s), we need to have general (inline) functions where the stack
and such is not hard-coded.

Tested on a real hw with configCHECK_FOR_STACK_OVERFLOW == 2 and
portSTACK_GROWTH == -1.

Just compile tested for portSTACK_GROWTH == +1.

Would be nice if you could mainline this.

Regards
Friedl

rtel wrote on Monday, February 11, 2013:

I have not done more than glance at this one yet.  I understand the desire to generalise the stack checking, but the patch is not there yet because it uses inline functions (remember FreeRTOS officially compiles with 18 different compilers so avoids using inline as different standards treat it differently ).  Also, the checking has to be very fast, hence the macros that are expanded inline rather than function calls.  I’m not sure (because I don’t use them often) if the compiler will always perform a direct substitution for an inline function without any parameter overhead.  I suspect most compilers will as soon as you turn any kind of optimisation on.

I will look at what you are trying to achieve to see if there is an alternative that does not use the inlines.

Regards.

rtel wrote on Monday, February 11, 2013:

Only partially related - I would be interested to know what you are porting to.

Regards.

friedl wrote on Monday, February 11, 2013:

I will look at what you are trying to achieve to see if there is an alternative that does
not use the inlines.

I used the inline to get type checking while using defines.

Because the inlines are in a .h file the compiler has to put
the code where the define goes. Am I wrong?

Regards Friedl

friedl wrote on Monday, February 11, 2013:

I would be interested to know what you are porting to.

It’s not 8051 :slight_smile:

Regards
Friedl