#81 "critical" could do better job



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

    Maarten Brock - 2004-10-19

    Logged In: YES

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

  • Stas Sergeev

    Stas Sergeev - 2004-10-19

    Logged In: YES

    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
    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

  • 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.


  • Maarten Brock

    Maarten Brock - 2016-04-30

    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 { ... }


    Last edit: Maarten Brock 2016-04-30
    • 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.


      • Stas Sergeev

        Stas Sergeev - 2016-04-30
        Last edit: Stas Sergeev 2016-04-30
  • Maarten Brock

    Maarten Brock - 2016-04-30

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

  • Maarten Brock

    Maarten Brock - 2016-05-07
    • status: open --> closed-fixed
    • assigned_to: Maarten Brock
    • Group: -->
  • Maarten Brock

    Maarten Brock - 2016-05-07

    Implemented in SDCC 3.5.6 [r9593].



    Commit: [r9593]

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.

No, thanks