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 14:02
Read: 636 times

#187562 - In discrete mathematics proving one is not a proof
Responding to: Per Westermark'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.

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
Where can one learn Intermediate C techniques for 8051      David Good      05/22/12 17:42      
   on the right track        Maarten Brock      05/23/12 06:11      
      one more thing      Erik Malund      05/23/12 07:15      
         Not uncommon bid bad coding standards to comply with      Per Westermark      05/23/12 08:14      
         Not afraid of globals, but...      David Good      05/23/12 10:07      
   More keil optimizer interesting tidbits      David Good      05/24/12 16:24      
      optimization      Maarten Brock      05/25/12 05:35      
      nothing gained, nothing lost      Erik Malund      05/25/12 07:53      
         I don't      Per Westermark      05/25/12 07:58      
            you can do both      Erik Malund      05/25/12 09:44      
               That is not helping the compiler      Justin Fontes      05/25/12 16:31      
                  exact same      Maarten Brock      05/26/12 03:36      
                     Technically, they are not the same      Justin Fontes      05/26/12 11:17      
                        Hmmm...      Andy Neil      05/26/12 23:46      
                        C don't do full evaluation of logical expressions      Per Westermark      05/28/12 06:33      
                           In discrete mathematics proving one is not a proof      Justin Fontes      05/28/12 14:02      
                              Lazy evaluation demanded        Per Westermark      05/28/12 14:51      
                                 I have learned something new because of this      Justin Fontes      05/28/12 17:54      
                                    me too      Andy Peters      06/01/12 11:43      
                                       Very Important      Michael Karas      06/01/12 14:30      
                              Breaks.      Michael Karas      05/28/12 17:57      
                                 Compile the code      Justin Fontes      05/28/12 18:28      
                                    To be more exact      Justin Fontes      05/28/12 19:11      
                                       Stop It!!        Michael Karas      05/28/12 22:01      
                                          That is exactly what I intended      Justin Fontes      05/29/12 10:16      
                                             Switch Break.      Michael Karas      05/29/12 22:04      
               obfusciating code to help the compiler is a VERY bad idea      Andy Neil      05/27/12 07:13      
                  the source of this      Erik Malund      05/27/12 07:17      
   Where can one learn Intermediate C techniques for 8051      Andy Neil      05/26/12 23:56      
   Getting the least out of your compiler        Andy Neil      05/27/12 07:25      
      Maybe IAR should follow their own advice?      Christoph Franck      05/30/12 02:05      
         provided the case ...      Maarten Brock      05/30/12 06:29      
            Compilers not knowing the target chip.      Christoph Franck      05/31/12 03:19      

Back to Subject List