| ??? 05/05/08 17:10 Read: times |
#154436 - Re: assumptions Responding to: ???'s previous message |
Erik said:
here is another eaxmple where "a sufficiently smart compiler" might figure it out, but Keil definitely does not. what, coded in "Real C" was (in the same function)
if(ReadPagedFlashC((U16) &GE1_TXCHp->TXCHtype, GC_E1_TXINpg)) .... if(ReadPagedFlashC((U16) &GE1_TXCHp->TXCHtype, GC_E1_TXINpg)) .... if(ReadPagedFlashC((U16) &GE1_TXCHp->TXCHtype, GC_E1_TXINpg)) ....ad nauseam I would guess that no compiler could figure that one out. Consider that the ReadPagedFlash() function might be in a different module than the one being compiled, or even in a precompiled library of some sort that the present compiler knows nothing about. So the compiler has no choice but to call ReadPagedFlash() for each of the 'if' statements because for all it knows, ReadPagedFlash() might return a different result each time it is called. Erik said:
I changed to
PCHCtype = ReadPagedFlashC((U16) &GE1_TXCHp->TXCHtype, GC_E1_TXINpg); if (PCHCtype) .... if (PCHCtype) ....both examples are, of course, correct, but which is the efficient one (both code size and speed) You can't really say that the second example is correct without the additional qualification that ReadPagedFlash() returns the same result each time it is called. No doubt your human brain knew that intuitively because you either wrote or studied ReadPagedFlash(), and so you were able to make the optimization without a second thought. But in a sense, you didn't really make it "easier" for the compiler to do the optimization; you did the optimization manually by applying information that the compiler had no way to get on its own. This is pretty interesting stuff. I know what you're trying to get at, and I've been trying (without success) to come up with a better example. It may be that with any given compiler, you can improve things by coding in certain ways that overcome the shortcomings of that particular compiler, but that a compiler that's "sufficiently smart" in every respect will optimize to the same result for all equivalent programs, no matter how they're coded. I think this is more or less what Jan was saying here. -- Russ PS: What do you mean when you talk about "Real C"? |
| Topic | Author | Date |
| "Real C" vs '51 C | 01/01/70 00:00 | |
| there is nothing wrong except... | 01/01/70 00:00 | |
| if you are not , why are you even here | 01/01/70 00:00 | |
| *(buffer+8+index)? | 01/01/70 00:00 | |
| none of the above | 01/01/70 00:00 | |
| OK then how? | 01/01/70 00:00 | |
| like this | 01/01/70 00:00 | |
| but it's basically the same... | 01/01/70 00:00 | |
| YCMV | 01/01/70 00:00 | |
| No | 01/01/70 00:00 | |
| assumptions | 01/01/70 00:00 | |
| Re: assumptions | 01/01/70 00:00 | |
| I took a \'known\' example | 01/01/70 00:00 | |
| Compiler-independent efficient C | 01/01/70 00:00 | |
| a clarification and an example | 01/01/70 00:00 | |
| Two kinds of "efficiency" | 01/01/70 00:00 | |
| Compiler smarter than coder | 01/01/70 00:00 | |
| Getting the least out of your compiler | 01/01/70 00:00 | |
| Real C is inherently reentrant | 01/01/70 00:00 | |
which, even when possible, often is ill advised | 01/01/70 00:00 |