On 2006-09-13, Steve Hosgood <st...@caederus.com> wrote:
>>Sorry if I sounded a bit shrill, but you're suggesting a
>>compiler which refuses to compile 100% legal standard ANSI C
>>source code. I just don't see how that's a real option.
>>
> That's more like it!
>
> Sorry, Steve Underwood, but Grant's right. That's not to
> belittle the efforts of you and Dmitry over the years getting
> all this stuff working, it's a great toolset. It just gets
> bugs sometimes.
I certainly didn't mean to sound ungrateful, but I was a bit
shocked at the suggestion that memcpy/memset to/from odd
addresses not be allowed.
> I've been a compiler maintainer (on a home-grown Tiny-C about
> 20 years ago). I know what it's like. No-one congratulates you
> for the great code the compiler generates 99.9% of the time,
> they just winge about the 0.1% stuff!
Well, I would like to thank and congratulate the msp430
creators and maintainers. I've contributed small bits and
pieces of code to the gnu toolchains over the years, but
nothing that's even close to creating and maintaining a port.
> But as I said, Grant's right. The compiler *must* generate
> runnable code (if it is to generate anything). It doesn't have
> to be *good* code, but it must run.
>
> Normally, the compiler should avoid alignment issues by
> padding structs and things so that they can't get misaligned,
Even that's not possible when the source/destiation is a byte
in a byte array. Unless you're going to change 'char' to 16
bits, you can't expect every possible source/destination to be
word-aligned. I think changing char to 16 bits would be a
disaster.
> but if the user uses #pragmas or other constructs to force
> unaligned data
You don't even have to use pragmas or attributes. Simply
doing this triggers the bug:
char foo[32];
memcpy(&foo[5],&foo[16],2);
(I suppose a char array is technical an "other construct", but
it's certainly not in the same category as nested packed
structs.)
> then probably the best thing is to generate whatever crap code
> that it needs(*), and generate a warning that the alignment
> problem is causing a problem.
Hmm. I don't think that there should be a warning in any of the
cases I've been whinging about.
Why should the programmer who wrote the code above see a
misalignment warning? He shouldn't, because nothing is
misaligned. The programmer is asking for byte operations. All
of the bytes are on byte boundaries.
The "misalignment" happens because the compiler has erroneously
decided to substitue a single word instruction for what was
written by the programmer as two byte operations.
IMO, the compiler can't complain anytime a source or
destination address isn't even.
> (*) In the illustrated case (earlier) that would seem to be
> two mov.b instructions to shift a single 16-bit misaligned
> quantity.
Except it's not a single 16-bit misaligned quantity. It's two
properly aligned single byte quantities. The compiler decided
to combine the two byte operations into a word operation even
though one of the addresses was odd.
Two mov.b instruction is perfect. It's exactly what the source
specified.
--
Grant Edwards grante Yow! Intra-mural sports
at results are filtering
visi.com through th' plumbing...
