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
*********************************************************************
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Mspgcc-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
