you'll get this with -O1 ~d
On Saturday 04 January 2003 01:09, Mark Stokes wrote: > Ok, well, that's no problem. I have no problem with telling the > compiler that I'm only interested in the lower words (explicitly). > > However the second "if" test _Doesn't_ do what I want. I want to > remove the extra R15 loads that are not even being used. > Example: > int16 = (unsigned int)int32; > 1184: 1e 42 04 02 mov &0x0204,r14 > 1188: 1f 42 06 02 mov &0x0206,r15 <<-- not > needed!! > 118c: 82 4e 02 02 mov r14, &0x0202 > > I also want the assignments and compares to perform on the RAM directly, > since it can. This would save the register loads. Example: > > 1184: 92 42 04 02 02 02 mov &0x0204,&0x0202 ;src > addr 0x0204 > > Would do the same thing w/o any extra register loads > > -Mark > > > -----Original Message----- > From: [email protected] > [mailto:[email protected]] On Behalf Of Dmitry > Sent: Friday, January 03, 2003 4:34 PM > To: [email protected] > Subject: Re: [Mspgcc-users] Byte/word compare optomizations > > > 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 *********************************************************************
