#39 more 'critical' improvements



I see bernardheld and epetrich have worked on my
previous question for a better 'critical' behaviour. They
came up with a better solution in some part than mine
(push psw), but that's mostly because I'm not familiar
with which registers can be thrashed and which not.
Only I see they did not use the proposed TEST BIT AND
CLEAR opcode. This is a pity because that made the
reading and disabling an atomic action. With the current
implementation it is possible an interrupt arrives between
the reading and the disabling which can turn interrupts
off when they were on. After the function ends the
interrupts will be enabled again which should not
happen, because they were switched off in the ISR.
Hope this will be fixed.

Now this was only a bug report. The real improvement
could come from instantiating a local bit variable to store
the EA state in. This way it won't cost an extra stack
position, but only a bit. If a critical function is called
from another critical function it costs two local bit
variables, etc. Of course this won't work for reentrant
functions which should use the stack.

Another big improvement would be if it were possible to
use this keyword not only for a function, but for any
compound statements block. Often you want to make a
single access to a variable atomic and calling a function
to do that brings a lot of overhead.

Hope to have helped improving the SDCC.

Maarten Brock


  • Erik Petrich

    Erik Petrich - 2003-10-22

    Logged In: YES

    Some of this is now implemented in the files noted in
    ChangeLog 1.468.

    The mcs51 and ds390 variants now test and clear EA atomically.

    The C front end now can parse the critical keyword in
    conjunction with a statement and generates bracketting
    CRITICAL and ENDCRITICAL iCodes. I implemented backend code
    generation for these iCodes for mcs51, ds390, and hc08. The
    break, continue, and return statements are not allowed to
    exit a statement oriented critical region, due to the
    complexities of handling the clean-up correctly. (Note that
    there is no limitation on the critical region size, since a
    compound statement block is one form of a statement)

    There is now some provision to store the interrupt state
    elsewhere than the stack, but this is not in use yet. Still
    need to handle the allocation of the storage. Since the
    linker is not doing cycle analysis, for the moment, I think
    the best one could do is 1 bit allocated for each function
    that used the critical keyword in some way (either for an
    entire function or some statements).

  • Maarten Brock

    Maarten Brock - 2004-11-18
    • status: open --> closed
  • Maarten Brock

    Maarten Brock - 2004-11-18
    • assigned_to: nobody --> maartenbrock
  • Maarten Brock

    Maarten Brock - 2004-11-18

    Logged In: YES

    SDCC 2.4.7 stores the interrupt state in a bit iTemp variable
    for mcs51 unless --stack-auto is used.


Log in to post a comment.

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

Sign up for the SourceForge newsletter:

No, thanks