On 2006-09-13, Steve Underwood <ste...@coppice.org> wrote:
>>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.
Exactly what "misalignment issues" are we talking about?
> If the code handles them properly, you really won't like the
> result.
Generating fast but incorrect code is better?
In the case of memcpy(&dest,&src,2) what is generated now is
mov.w &src, &dest
...even when src and dest are static and one is known at
compile time to be at an odd address.
The obvious alternative is to generate two byte moves in the
cases where the compiler doesn't know that both src and dest
are aligned:
mov.b &src, &dest
mov.b &src+1,&dest+1
That works just fine and there is no faster solution.
Or just calling memcpy() would work fine as well. In the case
I showed, the compiler _knows_ (or ought to) the destination
address is odd.
There's no excuse for generating an unaligned mov.w -- no
matter how much more fast and compact it is compared to code
that actually does what the source file specifies.
> The MSP430 doesn't allow misaligned loads and stores,
I wasn't attempting to do a misaligned load/store. I was
attempting to call memcpy().
I'm not asking for assigments to misaligned packed fields to
work (though they do for plenty of other targets such as the
ARM).
> so they have to be simulated by a mass of instructions.
So you're saying that calling memcpy() with pointers to odd
addresses is going to be disallowed because the compiler might
choose to use broken intrinsic memcpy code that only works for
even addresses?
> The slow bulky code that produces isn't going to please many
> people.
Nonsense.
Moving two bytes with two mov.b instructions isn't slow or
bulky. There simply isn't any better way to do it if the two
bytes cross a word boundary.
> Should we just say no misalignment is permitted?
Huh? What does "no misalignment is permitted" mean? I'm pretty
sure if you don't allow 8-bit bytes to reside on odd addresses,
what you end up which can't be called a C compiler.
If you're not going to permit any odd addresses to be used,
then you're going to have to make "char" 16 bits wide. On an
architecture with limited RAM, I don't think anybody's going to
like that idea.
> Maybe I should check how the other MSP430 compilers handle
> this.
Handle what?
--
Grant Edwards grante Yow! I don't know WHY I
at said that... I think it
visi.com came from the FILLINGS inmy
read molars...
