On 2008-02-14, Peter Jansen <[email protected]> wrote:
>>> Any unaligned struct members *and* structures themselves on
>>> RISC generally, i guess. Better to ask developers. There is an
>>> alternative -- byte by byte access.
>>
>> I don't understand. An "alternative" to what? It's what gcc
>> does on other targets when accessing misaligned packed struct
>> members.
>
> I noticed some time ago that there is some problem with GCC
> and pointers to structures and indexes, its a bug in how gcc
> handles structures and should compile to the correct code, but
> does not. The compiler should compile what you ask of it, if
> it does not its a bug. The original post this seemed to be the
> case. Give us a test case of code that does not work and it
> might be fixable, without that I don't know what is wrong.
>
> This is independent of how data is aligned in memory.
I'm afraid you've lost me completely. I thought the OP was
complaining about mps430-gcc not generating correct code for
accessing misaligned fields in packed structs.
>>> But how efficient it can be? Better to have good _design_
>>> right from the start.
>>
>> If you don't get to define the layout of the data in memory, I
>> don't see how you can "design" your way around doing byte by
>> byte access of misaligned values.
>
> char array[128] is always in sequence and you have control of how that
> is aligned in memory. You put them in in sequence and incrementing a
> pointer to them always gets you the characters in sequence.
Right.
> now,
>
> struct
> {
> char x;
> int y;
> char z;
> long b;
> char v[128];
> }
>
> Can be in any sequence the compiler likes to lay it out, even
> 'packed' (use minimum memory).
No, it can't. The C standard requires the fields to be layed
out in memory in the sequence in which they're declared, and
that's what gcc does. The compiler is allowed to place padding
"between" fields, but it isn't allowed to rearrange.
Technically, I believe it can if it can be known at compile
time that such a rearrangment will not affect program
execution. But I'm not aware of any compilers that can do
that.
> Incrementing a pointer to this struct will not always get you
> x then y high, y low etc...
Incrementing a pointer to that struct will get you a pointer to
the memory _after_ that struct, not a pointer members of that
struct.
> It depends on the machine, the compiler, the final alignment
> in memory etc. C says thats its upto the compiler how to lay
> this out in memory. Its non portable, yes a lot of examples
> make this mistake, but its not how ANSI C is specified.
I'm not sure what point you're trying to make. Are you
disagreeing with the statement that for other targets, gcc
generates correct code when accessing packed structs and
doesn't for the msp430 target?
> If you want to control the layout in memory then use an array.
> It should not matter what the layout is in memory for your
> code to work.
Using packed structs for things like communication protocol
structures works very well (at least on unbroken compilers).
Using an array instead make the code hard to maintain.
> If your using pointers to type cast between variable types (or
> structs) then you should be carful, type casting with pointers
> is dangerous, and the compiler tries to warn you of this where
> it can.
I wasn't aware we were discussing type casting...
--
Grant Edwards grante Yow! Yow! Those people
at look exactly like Donnie
visi.com and Marie Osmond!!
