#81 "critical" could do better job

None
closed-fixed
None
5
2016-05-07
2004-07-16
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.

     
  • 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

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

    Maarten

     
    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.

      Philipp

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

     

    Related

    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