Code is not generated for the char data types

Well, I added the c4 variable so now the compiler should produce result for c3.
Now the compiler is placing NOP instruction for all the 4 statements.

I wish to store this data in EEPROM later on in my project. Hence i was considering the datatype char.

#include <lpc214x.h>
#include <stdio.h>
#include <ctype.h>

main(){
char c1,c2,c3,c4;
 c2 = 2;
 c1 = 15;
 c3 = ch1 * ch2;
 c4 = ch3 * 2;
}

I am using MDK LITE VERSION for Arm. Do I have to add any other ".h" file for it to compile properly?

regards
Satish

In this case, there is two interesting things with the source code.

One is that c3 is never used, which removes the need for assigning a value to c3 and hence the need for using the values of c1 and c2.

The other issue is that c1 and c2 are loaded with constant values, which means that c3 will also always receive a constant value.

Well, I added the c4 variable so now the compiler should produce result for c3.

No, it should not. This is still dead code.

If you really REALLY want to see code generated for those variables (why would you want to, by the way?), declare the variables as static volatile.

"I am using MDK LITE VERSION for Arm. Do I have to add any other ".h" file for it to compile properly?"

It _is_ compiling properly. But c4 isn't used. So it can be thrown away. Then c3 isn't used so it can be thrown away. But then c1 and c2 are not used so they can be thrown away. Your code don't do anything with the results of your expressions.

Think about it.

If you have a mail program and press "New mail". Then you press "Send". Would you think it correct of the mail program to send that empty mail - no receiver specified, no subject, no body?

Add a global variable:

volatile char test;

Then assign:

test = c3;

Now, the compiler knows that it is important to perform all reads/writes of "test" that the source code wants. So c3 will be used. Of course, the compiler can still figure out that 2*15 is 30 and - depending on optimization level - decide to just assign the value 30 to "tmp".

Don't think so much at this stage. Write some real code that performs a real task. Then start to think about if the program works or not. Or look at the produced output to learn how well the compiler is able to produce good machine code instructions. Or how much different C code constructs "costs" for the processor.

Thanks it works, I will remember your suggestion in future too.

Well I tried your suggestion too, now i am able to see the code. The compiler are getting too smart for us. :)

Thanks it works, I will remember your suggestion in future too.

Don't forget to remove static volatile in production code, otherwise code size and performance will suffer.

The compiler are getting too smart for us. :)

Don't speak for all of us :-)
It does take some getting used to. But that's the price you pay for efficient code, I guess.

"In this case, there is two interesting things with the source code."

both cases apply regardless of the data type (char vs. int here).

but that doesn't explain why the compiler generated the code for int not for char.

""but that doesn't explain why the compiler generated the code for int not for char."

The compiler authors/maintainers would probably know why. The best most here could probably do is speculate.

There might be some wasted code space - But apart from that, does it really matter?

No - but it's a great topic for speculation!

Perhaps we could even devise a conspiracy theory...

"The best most here could probably do is speculate."

bingo!

I was simply pointing out that we don't really know definitively / authoritatively why the compiler behaves in certain ways. so we should present our opinions as our opinions, not as the absolute truth.

all we can do is to speculate and propose a solution and hope for it to work.

nobody claimed that we do!

In fact, it was noted as being strange that the behaviour differs for char or int...