??? 05/28/12 20:02 Read: times |
#187562 - In discrete mathematics proving one is not a proof Responding to: ???'s previous message |
There are a couple of arguments going on here.
The main argument being that is if the hex file is different the logic and processes are different. I have tried to make this point clear in the past two posts. me said:
The hex file is different because the logic is different. and me said:
I'd suspect that a compare for a while(1) would be generated if the compiler did not handle this for the user, but the hex file would be seen as different. So, to pull another quote out of context is confusing this point. This is in reference to the quote you quoted. If the hex file is not different, then there will be no change. In every test I have done there has been no changes in the hex file whether one uses for(;;) or while(1), but this goes against what Erik said. Erik said:
while(1) and
for (;;;) creted diferent code So, either Erik is not telling us something, but that is doubtful, or all of my compilers do not mimic his. Which one is more plausible? Proving a discrete set is not going to prove the full set. Even Andy presented a paper that stated The C standard defines what is considered "the same", and sets the limits of allowable optimizations. I guess one would have to dive into this large document to get an idea of what this could mean, exactly. However, that sentence does make a single point clear ---- the compiler cannot over optimize, but the compiler CAN UNDER OPTIMIZE. Secondly, I believe you are correct about the if statements with your compiler, but there is a slight hiccup. There is no way a break can be used after an if statement. A break only applies to a loop. The code Erik mentioned is not correct. This argument is more or less null and void because of this, but I did create different C code that had identical assembly. Meaning that argument 1 applied in this case and must first be avoided to show a difference. Using a return in several places automatically increases processes, regardless. So, the assumption that the if statement(s) is causing the difference is incorrect and misled the argument from the start. Erik said:
if ( a && !b && !c)
created code different from if (a) { if b break; if c break; However, under the guise that the compiler is not hitting the speed limit of the standard C Optimization ruling and that it is under optimized, the true logic would be to guarantee that all values are tested and that's a strict logic. I am unsure how the C Standard came up with rules to say that certain logic is "the same" and has no impact upon programming because as my analogy showed earlier, fractions with totally different numerators and denominators can have a huge impact on results and cannot be considered to be the same in the case of statistics. So, I guess there are some cases in C, but that seems a little un-trustworthy. |