Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo

Close

#81 "critical" could do better job

open
nobody
None
5
2004-07-16
2004-07-16
Stas Sergeev
No

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.

Discussion

  • Maarten Brock
    Maarten Brock
    2004-10-19

    Logged In: YES
    user_id=888171

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

     
  • Stas Sergeev
    Stas Sergeev
    2004-10-19

    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.