• State Not Answered
  • Locked Locked
  • Replies 4 replies
  • Subscribers 22 subscribers
  • Views 1051 views
  • Users 0 members are here
Options
Related
How was your experience today?
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Stack Pointers

S. Gupta

We are using our own developed RTOS,

Our developed software is working fine up to optimization level 6, but when we change the level to 8, the software was not working. We observed that the stack pointer is not same as we level 6. In level 6 when we are calling a function SP was going incremented with 2. Again from the function if we are calling another function than again SP is incrementing by 2.

But in level 8 we observed that in above case SP is incrementing by 2 and not by 4.

So we made necessary corrections in our RTOS related software and it worked.

After working with level 8 we changed the level to 9. But this time also the software having problems. So please give information about stack Pointers. How it is working (SP) with different optimization levels.

  • 0

    Your RTOS is incompatible with one of the optimizations performed at OP(8), most likely the one the streamlines tail recursions. This optimizes

       lcall foo
   ret
    into the shorter, faster, and less stack-hungry alternative
       ljmp  foo
    If your RTOS can't handle this optimization, you should re-think its design --- it's making unwarranted assumptions about the compiler.

  • 0 in reply to HansBernhard Broeker

    Can we see in the SRC files, that "As you mention lcall foo >> ret,

    the compiler generate ljmp foo

    if we can check in the SRC files, Please guide us, where we can check.

  • 0 in reply to S. Gupta

    Feel free to stare at the listings (not at SRC files, but *.lst files from normal compilation runs) --- but don't expect much help from that exercise.

    Checking whether the compiler did indeed perform this optimization is beside the point. You already detected the main effect: the stack usage has decreased by one level of lcall --> 2 bytes, i.e. from 4 bytes to 2 in a nested call situation.

    It's not perfectly clear, but you seemed to be saying in your original posting that this difference in stack pointers caused misbehaviour of your task switcher. If so, your task switcher has a bug that needs fixing: it absolutely may not depend on the compiler generating LCALLs for every function invocation, if it wants to cooperate well with Keil C51 at higher optimization levels.

  • 0 in reply to HansBernhard Broeker

    "Feel free to stare at the listings (not at SRC files, but *.lst files from normal compilation runs)"

    You might also need to enable & inspect the *.COD file from the Linker, as (some of) the higher optimisations are perfomed by the Linker, not (just) the Compiler...