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.
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
ljmp foo
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.
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.
"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...