#81 "critical" could do better job

[Stas Sergeev]

Hi.

I have a program here that sits very low on memory.
Something like 35 bytes are free. One function in that
program is a stack-eater - it eats up about 20 bytes on
a stack. If the interrupt handler is executed while whithin
that function - stack overflow.
I tried to avoid the problem by marking the stack-hungry
function "critical" to prevent the possibility of it to be
interrupted. But it still locked up after some time.
It turned out that the interrupts gets disabled after the
stack pointer gets incremented in the function prolog,
which leaves a small window where the inthandler kills
the program.
I think making sdcc to disable the interrupts before
incrementing the stack pointer, may not be difficult.
Can this be done?
Right now I have to enforce the callers to
disable/reenable interrupts themselves.

[Maarten Brock]

Logged In: YES
user_id=888171

This clashes with the desire to keep interrupts off as short as
possible.

[Stas Sergeev]

Logged In: YES
user_id=501371

Yes, but it is really only one-two asm instructions, and as the
reward you get something really usefull.
Actually, expecting that the "critical" will prevent the
stack overflows on an interrupts, is very natural. It almost
looks like a bug that it doesn't.
Note: if you want to protect only some code, you can use
the "critical" keyword locally. It is probably even the
preferred
way. So when I use it globally, I really mean that I don't care
about the higher interrupt delays, but I really want to be
protected.

[Philipp Klaus Krause]

I agree with Stas Sergeev here, and suggest to change the mcs51, ds390, hc08 and s08 backends accordingly. The z80, z180, r2k, r3ka, tlcs90, gbz80 and stm8 backends already disable interrupts before adjusting the stack.

Philipp

[Maarten Brock]

I seem to remember I proposed (probably on the mailing list) to change the language to accept __critical before the interrupt function name to indicate this request. And after the function name is identical to before the function block and thus disables as short as possible.

__critical void ISR_with_early_disable (void) __interrupt(1) { ... }
void ISR_with_late_disable (void) __interrupt(2) __critical { ... }

Maarten

[Philipp Klaus Krause]

On the other hand, those wanting to keep the time during which the interrupts are disabled as short as possible will probably not mark whole functions as critical anyway, instead using the more fine-grained possibilities of critical blocks.

Philipp

[Stas Sergeev]

[Maarten Brock]

Ok, let's go and implement this feature request.

[Maarten Brock]

Implemented in SDCC 3.5.6 [r9593].