We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
I have a segment of codes as follows. 'app' is a structure variable.
The code can successfully pass the compiling process and run but contains some inexecutable important commands, which can't be recognized by compiler, e.g.app.bT = TRUE. Besides, there are some disordered jump inside the switch, e.g. jumping from case 1 to case 5 without executing "break" in case 1.
app.bT=FALSE;
do {
switch ( ix )
{
case 0: if ( app.f0< app.fB1 ) app.bT = TRUE; break;
case 1: if (( app.fB1 <= app.f0 )&&( app.f0<= app.fB2 ) ) {if ( app.fC1 > ( ( app.fM1 * app.f0 ) +( app.f_Allowed - app.fM1* app.fB2 ) ) ) app.bT= TRUE; } break;
case 2: if ( app.f0>app.f_Allowed) app.bT = TRUE;
break;
case 3: if (( app.f0 <= app.fB4 ) ) { if ( app.fT > ( ( app.fM2 * app.f0 ) +( app.f_Allowed -app.fM2*app.fB3 ) ) ) app.bT = TRUE; } break;
case 4: if ( app.f0> app.fB4 ) app.bT = TRUE; break; default: break;
}
ix++;
while ( ix < 5 && app.bT == FALSE );
I think it's the internal error of C51 since there are few other explanation for this strange problem but I still don't want to believe that's true. Would you please give me an answer? Thank you for your help.
Thank you so much!!!!
I followed your advice to reduce the optimazation level from 8 to 7 and the problem has been solved. But I can't believe why the default optimazation level is set 8, which may have a large potential to cause many problems.
"which may have a large potential to cause many problems"
What actual problems have you seen?
What you have described is perfectly normal behaviour for any optimised code - whether machine-optimised, or hand-crafted by a skilled assembler programmer.
The "problems" you describe are merely (sic) in debugging - they should not affect the overall operation of the code...
I am sorry but I can't agree with you. I have run the program many times when the compiling was high optimized. Every time I ran and traced the execution of every statement inside the switch, some statements, e.g. app_bT=TRUE, could not be recognized as an executable while they should have been, besides there were disordered jumps between cases, e.g. from case1 to case 5, which I believe is absolutely wrong.
What Christoph Franck told me is right. It is the problem with compiling optimization. When I reduce the optimization level by one, all the statements can be recognized and transformed into executable machine codes and ran normally.
You've missed the point!
'C' does not guarantee that your source lines will be executed in sequence, step-by-step.
eg, think about why the 'volatile' keyword exists...
So long as the overall effect is the same, the program is operating correctly!
Re-ordering instructions within case statements is a classic example of optimiser behaviour for any compiler; Similarly, combining common exit and entry code for functions; And deleting superfluous operations...
If you just run the program with and without optimisation, and without trying to trace through it, can you actually tell the difference? If not, then there is no problem. If you can tell the difference, that is far more likely to be a flaw in your source than fault in the compiler!
"e.g. from case1 to case 5"
If you want to discuss your code, please re-post it properly - I can't even see a case 5 in your original post!
No the source code has never been changed. When I increase the optimization level from 7 to 8, the problem occured again.
I understand what you said about the 'volatile' and reordering, but I can tell you clearly that I have traced the execution of every statement step by step, and what I observed is that the execution sequence and result produced were totally different between two different optimization levels.
Thank you for your concerns.
There are 8 cases inside the codes, but there are no big difference between statments inside those cases. So I just posted 4 with respect to efficiency. I am sorry about that.
What I want to tell you is that, when the code contains complex statements with 'do while', 'switch' and 'if' statements inside, you should not set the code optimization level very high in order to prevent such errors.
"No the source code has never been changed."
Of course not - optimisation does not affect the source code! Optimisation is performed on the Object code!
"When I increase the optimization level from 7 to 8, the problem occured again."
What problem? When you use high-level optimisations like this, you will never be able to simply follow the source lines in generated machine code - that's the whole point! An optimiser will always re-order code, remove unnecessary code, etc, etc to achieve its goal! That's what optimisers do!
"I observed is that the execution sequence..."
The execution sequence is irrelevant, and must be expected to change - see above.
"...result produced were totally different"
The final result, though, should be identical - aside from timing.
If the final result is really different, then you most certainly do have a problem! In what way is the final result different?
"are no big difference between statments inside those cases."
Which is exactly the kind of thing that an optimiser will spot, and then it will re-order the code to avoid the duplication!
" I just posted 4 with respect to efficiency"
But what you posted was totally illegible, wasn't it?!
"What I want to tell you is that ... you should not set the code optimization level very high in order to prevent such errors."
That is misleading advice!
You could justifiably say, as many have before, "if you want source-level debuginng, do not use high optimisation" - but to claim that the higher optimisation levels produce faulty code certainly needs some serious evidence!
Thank you for reminding me about these issues. I have learned a lot from what you told me.
This time I got the point you have tried to tell me. What I have traced is the optimized sequence and the result should be the same. I admit that what you said is right.
For proprietary consideration, I am sorry I can't post the whole source codes.
"I am sorry I can't post the whole source codes"
The fact that it was just an extract wasn't the issue - the real issue was that it was unreadable, because you hadn't followed the instructions about using the tags...