Grant Edwards wrote:
On 2006-09-12, Neil Wyper <nwy...@gmail.com> wrote:
My program is broken because mspgcc 3.2.3 is generating
unaligned word accesses. I'm calling memset() and memcpy()
fill in the fields in a packed struct. Since I've requested a
2-byte copy/set mspgcc is optimizing some of those memset()
and memcpy() calls into mov.w instructions, but the
destination address isn't word aligned, so the generated code
is not correct.
It appears to be doing the same thing for 4-byte memcpy()
operations. :(
This was noted on the list a year ago:
http://www.nabble.com/memcpy-assumes-16-bit-alignment--t712619.html
That sounds like the same problem. Especially the unsupported
relocation (which happens if you do an assignment to a
misaligned packed struct field).
[Since the compiler knows the structure is packed and the
destination field is misaligned, it should be able to generate
correct code for the assignemnt, but that's a slightly
different problem.]
What I don't understand is that thread's discussion of the
memcpy() code that's in libc. If it's the same problem, then
it's got nothing to do with code in libc.
msp430-libc/src/string/bcopy.c hasn't changed since then, so
the bug is still present.
If that previous bug was in libc code, then this is a different
problem. The bug I'm reporting isn't in libc, it's in the
compiler. If you note the generated code in my original
posted, memcpy() is never called.
The compiler generates a mov.w instruction with an odd
destination address. The compiler has generated an instruction
that isn't allowed by the architecture.
Besides the fact that memcpy() isn't being called in the
failure cases I've described, I've analyzed bcopy.c, and I
don't see anything wrong with it. Unless somebody can point out
exactly where the bug is, I'm going to have to say the posters
in the original thread were wrong about there being a bug in
libc's memcpy().
If you don't trust my judgment (no reason you should
particularly), there's also the fact that the bcopy.c in
msp430-libc is the standard BSD library code that's been beaten
to death for a over dozen years on as many acrictures (many of
which have memory alignment requirements like the MPS430). I
just checked the FreeBSD CVS repository, and that code is still
in use in FreeBSD systems today.
There's no bug in the libc memcpy().
The thread from last year did include a possible replacement
memcpy() from Daniel Néri.
There's no bug in memcpy(). The compiler isn't even calling
memcpy() in the code that's failing.
I'm _guessing_ that by providing his own memcpy() function, the
user is preventing the compiler from using the (broken)
intrinsic code that assumes 16-bit alignment for operations
greater than 1 byte long.
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.
Steve
