On 2006-09-13, Steve Underwood <ste...@coppice.org> wrote:
> Obviously, the compiler should deal with things like memcpy
> and memset correctly. These things are defined to work at the
> byte level, so they must. If you look back a few messages I
> actually said it needed fixing, but the question was how.
> Should the smallest possible, or fastest routine be used?
> Should we do in-lining, or call a function? These are valid
> questions, yet resulted in abuse.
I apparently misunderstood. I was under the impression that
"complaining and generating nothing" was being suggested for
the situation when one called memcpy or memset with odd address.
> What should happen with other stuff that is unaligned is less
> clear. I was hoping for some discussion on that, but fights
> seem more popular this week.
>
> In my experience, compilers typically do what mspgcc currently
> does now. If you try to access an unaligned integer in a
> structure on a processor which doesn't like it, they don't
> warn you, but the code crashes. That's what the Alpha and MIPs
> compilers I have used did.
I guess that's acceptable.
IIRC, the ARM and 68K backends will generate extra instructions
for cases where it knows the field is (or may be) unaligned in
a packed struct. If the compiler can figure out that a word
access is going to be mis-aligned, a warning would be cool
> Later versions of Alpha allowed misalignment with a speed
> penalty, like the x86. I'm not sure if MIPs ever changed. Now,
> the question is, what do people really expect on a thing like
> the MSP430.
This is the first time I've used a compiler that didn't
generate correct code when accessing a packed structure. I
expect problems if I dereference a pointer with a misaligned
value (I've tripped myself with that one on both gcc/ARM and
gcc/68K), but I don't expect problems when calling
memcpy/memset or when I'm directly accessing a field in a
structure that the compiler knows is packed.
> If you try something like
>
> struct
> {
> int x;
> char y;
> } xxx[10];
>
> and loop through the array accessing x, all is well. If you pack the
> structure it fails with mspgcc.
That works for all other gcc targets I've used (though I think
ARM and 68K are the only targets I've used that have strict
alignment requirements).
As long as memcpy/memset work, I wouldn't complain too much.
> The only real difference in the generated code is the loop
> steps 3 bytes at a time instead of 4. Now, if you try this
> with the IAR compiler for the MSP430, things still work with
> the packed structure. However, to achieve that complex code is
> produced when the structure is packed, and simple code is
> produced when it is not. Is this something people would like
> to see in mspgcc?
>
> Personally I wouldn't. Any significant amount of that kind of
> things would generate so much code it would be impractical.
Whether it's practical or not depends on whether you're short
on RAM or short on ROM. When dealing with externally defined
structures (communications frames), you've got no choice:
things have to be where they have to be. If the compiler
doesn't support direct accesses (assignments to/from) fields in
packed structures, then you use memcpy() calls.
> I was, however, naively hoping for some meaningful discussion.
--
Grant Edwards grante Yow! There's enough money
at here to buy 5000 cans of
visi.com Noodle-Roni!
