Probably, the compiler is not intellegent enough to make some suggestions like you (or somebody else do) and gcc does the thing it can (or how it's been written ...)
However: > 1) In the first example, the compiler is adding a bunch of extra loads. > Not to mention it is projecting the int to a long by clearing R13 and > including it in the comaprison (this is silly and actually incorrect). > I don't want the compiler to assume that high word is zero, if I wanted > that I would've asked for that. Also, in the assignment (int16 = > int32;), it loads R15 for absolutely no reason. How will you compare two different things - like diving and skydiving? Is there any reason to do that? Even if you would, you have to extend first one to another one - say assume you have some extra SCUBA diving equipment picularities like ability to work at 12000ft, or assume that skydiving can stop at 150 ft below the sea level. The first one is Ok - nothing gonna happen at 12K with mask. Another one is a bit tricky... I personally do not want to clean my rig after landing the way I'll be somehow below the sea level :) Therefore, when comparing two things - the common approach is to _extend_ one thing to another, not cut! You have to _extend_ 16-bits var to 32-bits var, not to cut 32-bits one half. So, the thing you see is zero_extend one _unsigned_ 16-bits to _unsigned_ 32-bits. In case they are signed - you'll get sign_extend of 16-bits to 32-bits var. So, the compiler just makes your life easier - you do not want to say that you want to extend 16 to 32 bits - it does it for you, cause most people think this way (how many actually will say that this is incorrect?). However, if you do not want to do this way, you'll have to say, that I would personally prefer to compare two different things the way one of them is broken - 32 -> 16 bits. So, your second > > 2) In the second if, I was able to force it to ignore the upper byte in > the compare by including the explicit type cast. However, it still > loads R15 unnecessarily (it's not even being used anywhere!). It also > loads R15 again unneccessarily in the assignment. > does the thing you want. The third is a bit tricky: > 3) In the third if, in an attempt to understand why a simple memory to > memory test is not being performed (which is possible). I had the > compiler test two regular int's. Amazingly, this resulted in the > compiler loading both values into registers and comparing registers. > This really doesn't make any sense to me. However, the compiler is > vedicated with the final assignment (int16 = int16;) because it finally > does what I'm expecting, it does a memory to memory assignment. Probably, I have to check operation cost again cause it seems to me that more and more people tend to use -O3 .. -O15932 (or whatever the number they do not understand) Just be... simple... try -O1. Do not try to amaze yourself. > > This example was compiled w/ the -O2 option. When I tried the -O3 > option I received the following error: > "testif.c:29: Internal compiler error in verify_local_live_at_start, at > flow.c:583 ... hm... see above and I will check this tomorrow. From the top of my brain - this code confuses gcc a lot - you assign volatiles and then compare them right away... well, this is perfectly correct, but... I'll check this anyway. cheers, ~d > Please submit a full bug report, > with preprocessed source if appropriate. > See <URL:http://www.gnu.org/software/gcc/bugs.html> for instructions." > > The version of the msp430-gcc.exe compiler I have is: > Length: 84,992 bytes > Date: 12/18/02 > > Thanks > -Mark Stokes -- ********************************************************************* ("`-''-/").___..--''"`-._ (\ Dimmy the Wild UA1ACZ `6_ 6 ) `-. ( ).`-.__.`) Enterprise Information Sys (_Y_.)' ._ ) `._ `. ``-..-' Nevsky prospekt, 20 / 44 _..`--'_..-_/ /--'_.' ,' Saint Petersburg, Russia (il),-'' (li),' ((!.-' +7 (812) 314-8860, 5585314 *********************************************************************
