On 2006-06-30, Chris Liechti <[email protected]> wrote:
>>>>Just for fun, I tried compiling the code with "two" changed to
>>>>an unsigned char. My mps430 compiler (3.2.3) then gives
>>>>
>>>> mov.b &P6IN, r15
>>>> rla.b r15
>>>> mov.b r15, &two
>>>> ret
>>>>
>>>>In other words, it makes the same mistake you did and
>>>>disregards the "volatile" qualifier. This is far more serious
>>>>than the original question - it is incorrect code, rather than
>>>>just inefficient code.
>> Rather than just complaining, I should try to fix it. Is this
>> something that could be fixed by somebody like me who's only
>> done minor hacking on GCC?
>
> if you already have an idea how the backend of gcc works i
> could think of "yes"
I've read descriptions of the backend, but never worked on it.
I've only tweaked a few things in the front end.
> gcc likes to output code for volatile acceess as
> load/modify/store, even when with the MSP430 a single mov,
> bis, bic/and would be fine too. there are extra optinizations
> by mspgcc to generate efficent code in such a case. that might
> also explain the different code at the two optimization
> levels.
It does generate correct code for -O0:
foo:
mov.b &0x0034, r15
add.b &0x0034, r15
mov.b r15, &two
ret
At -O1 and -O2, it generates the incorrect code as previously
noted.
> maybe someone could check with -mno-volatile-workaround
No difference. It still generates incorrect code for the
-O[12] case when the destination matches the width of the
source (both 8 bits wide). For the original case where the
destination i s16 bits wide, it stell generates an extra mov.b
and an extraneous and.b #-1,r15.
>> I see that there are several more recent versions of mspgcc in
>> CVS. Are any of the newer ones ready for production use? If
>> not, is 3.2.3 still being maintained?
>
> 3.2.3 is our "stable" version
Is it getting bug fixes?
> the latest 4.x should be the next version, but it's not yet
> ready
--
Grant Edwards grante Yow! YOU'D cry too if it
at happened to YOU!!
visi.com
