Email: Password: Remember Me | Create Account (Free)

Back to Subject List

Old thread has been locked -- no new posts accepted in this thread
???
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.

List of 33 messages in thread
TopicAuthorDate
Where can one learn Intermediate C techniques for 8051            01/01/70 00:00      
   on the right track            01/01/70 00:00      
      one more thing            01/01/70 00:00      
         Not uncommon bid bad coding standards to comply with            01/01/70 00:00      
         Not afraid of globals, but...            01/01/70 00:00      
   More keil optimizer interesting tidbits            01/01/70 00:00      
      optimization            01/01/70 00:00      
      nothing gained, nothing lost            01/01/70 00:00      
         I don't            01/01/70 00:00      
            you can do both            01/01/70 00:00      
               That is not helping the compiler            01/01/70 00:00      
                  exact same            01/01/70 00:00      
                     Technically, they are not the same            01/01/70 00:00      
                        Hmmm...            01/01/70 00:00      
                        C don't do full evaluation of logical expressions            01/01/70 00:00      
                           In discrete mathematics proving one is not a proof            01/01/70 00:00      
                              Lazy evaluation demanded            01/01/70 00:00      
                                 I have learned something new because of this            01/01/70 00:00      
                                    me too            01/01/70 00:00      
                                       Very Important            01/01/70 00:00      
                              Breaks.            01/01/70 00:00      
                                 Compile the code            01/01/70 00:00      
                                    To be more exact            01/01/70 00:00      
                                       Stop It!!            01/01/70 00:00      
                                          That is exactly what I intended            01/01/70 00:00      
                                             Switch Break.            01/01/70 00:00      
               obfusciating code to help the compiler is a VERY bad idea            01/01/70 00:00      
                  the source of this            01/01/70 00:00      
   Where can one learn Intermediate C techniques for 8051            01/01/70 00:00      
   Getting the least out of your compiler            01/01/70 00:00      
      Maybe IAR should follow their own advice?            01/01/70 00:00      
         provided the case ...            01/01/70 00:00      
            Compilers not knowing the target chip.            01/01/70 00:00      

Back to Subject List