This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
Re: structure size
- From: Bart Veer <bartv at ecoscentric dot com>
- To: olaf dot peters at technolution dot nl
- Cc: grante at visi dot com, ecos-discuss at sources dot redhat dot com
- Date: Tue, 6 Jan 2004 17:28:45 +0000 (GMT)
- Subject: Re: [ECOS] structure size
- References: <NGEBJAKIOFJPJPAKFEICKEFGCAAA.olaf.peters@technolution.nl>
>>>>> "Olaf" == Olaf Peters <olaf.peters@technolution.nl> writes:
>> Try the following:
>>
>> ------------------------------------------------------------------
>> struct xyzzy {
>> short a;
>> int b;
>> } __attribute__((packed));
>>
>> struct xyzzy data;
>>
>> int
>> fred(void)
>> {
>> data.b = 42;
>> }
>> ------------------------------------------------------------------
>>
>> Compile with arm-elf-gcc -S. The assignment to data.b is implemented
>> using four separate strb instructions, as I would expect. If you try
>> reading data.b instead there will be four ldrb instructions plus
>> appropriate manipulation.
Olaf> I noticed this behaviour too. But if you add a call to a
Olaf> function with a pointer to the unaligend member, things
Olaf> still go wrong because of an unaligned accesses.
Olaf> int assign42 (int *p)
Olaf> {
Olaf> *p = 42;
Olaf> }
Olaf> int
Olaf> fred(void)
Olaf> {
Olaf> assign42(&data.b);
Olaf> }
Olaf> I noticed this on an ARM7 core in the NetSilicon NET+50
Olaf> chip. However, that processor can generate a data-abort trap
Olaf> if an unaligned data access takes place. I used that trap to
Olaf> simulate the actual instruction and to assign the correct
Olaf> data. It works fine, but is probably not a generic solution.
Yes. As I said a couple of messages back:
There are also some things you really won't want to do, e.g. taking
the address of one field within a packed structure and then treating
that as an ordinary pointer.
When the compiler sees a function like:
int assign42(int* p)
{
...
}
there is no extra information here that the pointer might be to a
misaligned variable, so obviously the compiler is going to generate
the standard instructions rather than a slow sequence of byte stores.
Note that assign42() and fred() could be in separate files so it is
impossible for the compiler to figure this out. Instead it has to be
left to the programmer.
Currently there is no gcc syntax to specify that p is a pointer to a
misaligned variable. I think there were some discussions in gcc land a
while back about adding such a syntax, but things quickly get very
messy.
Bart
--
Bart Veer eCos Configuration Architect
http://www.ecoscentric.com/ The eCos and RedBoot experts
--
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss