On 2006-09-13, Peter Jansen <peter.jan...@aad.gov.au> wrote:
>> The real question here is what we should do about these
>> misalignment issues. If the code handles them properly, you
>> really won't like the result. The MSP430 doesn't allow
>> misaligned loads and stores, so they have to be simulated by a
>> mass of instructions. The slow bulky code that produces isn't
>> going to please many people. Should we just say no
>> misalignment is permitted? Maybe I should check how the other
>> MSP430 compilers handle this.
>
> The compiler MUST get the code correct for what is written.
> Fast code that is incorrect is useless, slow code that
> functions correctly is a much better option.
And in the case I posted, fast code that functions correctly is
quite simple.
> How many projects are pushing the outside of the envelope for
> speed/efficiency? If you want efficiency and you think you can
> write it faster in assembler then go ahead.
At the place in my program where the bug occurred, neither size
nor speed is essential. I knew the structures were packed and
therefore I couldn't depend on an assignment to work. What I
wanted was source code that was easy to understand and
obviously correct by examination. So I used memcpy to copy
data to/from packed structure fields.
I don't care whether the compiler just generates a call to
memcpy() or generates two mov.b instructions, but it's got to
be one or the other...
1. Prohibiting calls to memcpy() with odd addresses is out of
the question.
2. Generating incorrect code is also out of the question.
It would be nice if assignments to packed structure fields
worked as they do in some other targets with similar alignment
requirements, but I don't like to depend on that.
Let's not pretend this bug is caused somehow by using packed
structs either. Here's a prefectly legal, vanilla ANSI C
source file (no structs, packed or otherwise) for which the
compiler generates incorrect code:
------------------------------bug.c------------------------------
char foo[64];
void bar(void)
{
memcpy(&foo[5], &foo[24], 2);
}
------------------------------bug.c------------------------------
$ msp430-gcc -mmcu=msp430x148 -S -O3 bug.c
------------------------------bug.s------------------------------
.file "bug.c"
.arch msp430x148
[...]
bar:
[...]
mov &foo+24, &foo+5
ret
[...]
------------------------------bug.s------------------------------
That 'mov' instruction is illegal regardless of the address of
foo. Either the source or destination address _must_be_odd_.
--
Grant Edwards grante Yow! I'm definitely not
at in Omaha!
visi.com
