This is the mail archive of the ecos-discuss@sources.redhat.com mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: structure size


>>>>> "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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]