[ECOS] data alignment issues

[ECOS] data alignment issues

[Trenton D. Adams]

I figured I should start a new thread for this since it's slightly off
topic for that other question.

For those of you that are searching the archives, there's a bunch of
data alignment discussions under the subject "Network programming for
eCos under Linux". :)

Anyhow, I just ran a test.  I have the structure below.  All the char
fields are just dummy values to test data alignment issues when sending
the structure over the network to my PC.  Apparently, the PC compiler
and the arm-elf-gcc compiler align the floats the same because I didn't
have a problem at all.  I believe it was aligning them to 4-byte
boundaries because the sizeof () the structure was 40 where it should
have been 28.  So, that means 3 extra padding bytes per char.  I never
bothered to look at it in memory because I've forgotten how to read
floats in hex! :)

Any comments on this alignment?  I thought the gcc compiler didn't do
any alignment?

typedef struct
{
    /* version minor */
    unsigned short versionLS,
    /* version major */
        versionMS;

    /* current accelerometer voltage level */
    float accelerometerVoltage;
    char test1;
    /* current analog 1 voltage level */
    float analogVoltage1;
    char test2;
    /* current analog 2 voltage level */
    float analogVoltage2;
    char test3;
    /* current digital board voltage level */
    float boardVoltage;
    char test4;
    /* current rig temperature level */
     float rigTemperature;
} TStatusSignals;


Trenton D. Adams
Extreme Engineering
#17, 6025 - 12 St. SE
Calgary, Alberta, Canada
T2H 2K1

Phone: 403 640 9494 ext-208
Fax: 403 640 9599

http://www.extremeeng.com

Re: [ECOS] data alignment issues

[Grant Edwards]

On Thu, Aug 09, 2001 at 08:43:03AM -0600, Trenton D. Adams wrote:

> Why not send structures if it works?  After all, if I've tested it and
> there isn't any problems, then it's no problem right?

The problem is that it's fragile.  If one end moves to a
different version of the compiler, it could break.  If one end
moves to a different architecture, it could break.  If you're
willing to depend on both ends always using the same version of
the compiler running on the same architecture you'll be safe.

But someday, somebody may want to want to use a different CPU
on one end, or a different compiler version, and they will say
not-so-nice things about you.

-- 
Grant Edwards
grante@visi.com

RE: [ECOS] data alignment issues

[Trenton D. Adams]

What I use unions for is for readability mostly.  Take for instance my
structure and union below.  As you can see, both members of the union
are the same size anyhow (for my purposes) so it wouldn't matter in this
case.  I use it for clarity though.  If I was just to put the
commandParameters field in as an "unsigned long commandParameter",
someone looking at my code might not know what it means.  So, using a
union is perfectly clear as long as the other guy understands unions.

// Rig command structures for rig commands.
typedef union
{
    /* delay in seconds for the PAUSE ocmmand*/
    unsigned sDelay;
    /* What to set the RTC to for the INITIALIZE command*/
    unsigned long rtc;
} TCommandParameters;

typedef struct
{
    /* version minor */
    unsigned short versionLS,
    /* version major */
        versionMS;
    /* command to perform */
    unsigned command;
    /* parameters for the command */
    TCommandParameters commandParameters;
} TRigCommand;

-----Original Message-----
From: Andrew Lunn [ mailto:andrew.lunn@ascom.ch ] 
Sent: Thursday, August 09, 2001 10:05 AM
To: Trenton D. Adams
Cc: 'Andrew Lunn'; ecos-discuss@sources.redhat.com
Subject: Re: [ECOS] data alignment issues


On Thu, Aug 09, 2001 at 09:48:22AM -0600, Trenton D. Adams wrote:
> What about with unions?  When I know damn well both platforms have the
> same size for their primitive data types is it ok to copy an entire
> union to the buffer?   After all, the union will only be the size of
the
> largest data type, and no alignment issues should happen right?

Im not sure i follow what you mean.

If you have a union like

union {
        char    c;
        short   s;
        long    l;
} u;

Then the structure will normaly be 4 bytes long. But what use is such
a union? You normaly have a union of structures

union {
        a_t     a;
        b_t     b;
        c_t     c:
} u;

You then have the issue of how is the compiler aligning the data of
types a_t, b_t, c_t? 

Also, the C standard says "A union type describes an overlapping
nonempty set of member objects, each of which has an optinally
specified name and possible distinct type". I cannot see anywhere
which specifies how they overlap. One compiler may overlap them at the
beginning of the memory and another could overlap them at the end
of the memory!

        Andrew

Re: [ECOS] data alignment issues

[Andrew Lunn]

On Thu, Aug 09, 2001 at 09:48:22AM -0600, Trenton D. Adams wrote:
> What about with unions?  When I know damn well both platforms have the
> same size for their primitive data types is it ok to copy an entire
> union to the buffer?   After all, the union will only be the size of the
> largest data type, and no alignment issues should happen right?

Im not sure i follow what you mean.

If you have a union like

union {
        char    c;
        short   s;
        long    l;
} u;

Then the structure will normaly be 4 bytes long. But what use is such
a union? You normaly have a union of structures

union {
        a_t     a;
        b_t     b;
        c_t     c:
} u;

You then have the issue of how is the compiler aligning the data of
types a_t, b_t, c_t? 

Also, the C standard says "A union type describes an overlapping
nonempty set of member objects, each of which has an optinally
specified name and possible distinct type". I cannot see anywhere
which specifies how they overlap. One compiler may overlap them at the
beginning of the memory and another could overlap them at the end
of the memory!

        Andrew

RE: [ECOS] data alignment issues

[Trenton D. Adams]

What about with unions?  When I know damn well both platforms have the
same size for their primitive data types is it ok to copy an entire
union to the buffer?   After all, the union will only be the size of the
largest data type, and no alignment issues should happen right?

-----Original Message-----
From: ecos-discuss-owner@sources.redhat.com
[ mailto:ecos-discuss-owner@sources.redhat.com ] On Behalf Of Andrew Lunn
Sent: Thursday, August 09, 2001 8:55 AM
To: Trenton D. Adams
Cc: ecos-discuss@sources.redhat.com
Subject: Re: [ECOS] data alignment issues


On Thu, Aug 09, 2001 at 08:43:03AM -0600, Trenton D. Adams wrote:
> Why not send structures if it works?  After all, if I've tested it and

> there isn't any problems, then it's no problem right?  Is there any 
> better way sending data?  I suppose I could send the structure one 
> field at a time

What you are say is that it works today with gcc verions X for the
target, and MSVC version Y for the host. New version of the compilers
may decide to layout the structures differently. Borland may do
something different. The next versions of gcc may do something
different. MS may change there compiler. At that point, you have to
maintain old versions of the tools so you can rebuild your application. 

What you should do is add some marshelling code. That takes the fields
from the structures and places them into an char * array at well known
addresses. You can easily write this in a partable way.

If you are not interested in portability, you can use the gcc
extensions.

        Andrew

RE: [ECOS] data alignment issues

[rob.wj.jansen]

Trenton,

> Why not send structures if it works?  After all, if I've tested it and

Oops, this is where I hit the send button too fast. What I meant is that you should not do this right away
but first check what happens (as you did). I am used to have a seperate versions of structs for file/network
I/O and internal use, the same program on a different platform will only need the I/O one - plus functions
to populate - to be changed.

Depending on the compiler used (both are gcc I think) you could use a packed structure by using the
"__attribute__ ((packed))" on the struct definition. When you are using lots of chars and shorts this will
really make some impact on the size of the struct.

> I didn't mean I couldn't read a float in hex.  I mean I don't know how
> it's stored in binary.  As in 00001000.10000000 would be 8.5, but I

Thanks, you got me scared for a minute :-) I wrote a MC68000 floating point library in assembly and
this is not something you want to remember too long ...

Regards,

Rob Jansen

Software Engineer
Competence Center Platforms
BU Mobile Communications
Meijhorst 60-10, 6537 KT Nijmegen, The Netherlands
Tel: +31-24-353-6329
Fax: +31-24-353-3613
mailto:Rob.WJ.Jansen@philips.com

RE: [ECOS] data alignment issues

[Trenton D. Adams]

Point taken! :)

-----Original Message-----
From: ecos-discuss-owner@sources.redhat.com
[ mailto:ecos-discuss-owner@sources.redhat.com ] On Behalf Of Andrew Lunn
Sent: Thursday, August 09, 2001 8:55 AM
To: Trenton D. Adams
Cc: ecos-discuss@sources.redhat.com
Subject: Re: [ECOS] data alignment issues


On Thu, Aug 09, 2001 at 08:43:03AM -0600, Trenton D. Adams wrote:
> Why not send structures if it works?  After all, if I've tested it and

> there isn't any problems, then it's no problem right?  Is there any 
> better way sending data?  I suppose I could send the structure one 
> field at a time

What you are say is that it works today with gcc verions X for the
target, and MSVC version Y for the host. New version of the compilers
may decide to layout the structures differently. Borland may do
something different. The next versions of gcc may do something
different. MS may change there compiler. At that point, you have to
maintain old versions of the tools so you can rebuild your application. 

What you should do is add some marshelling code. That takes the fields
from the structures and places them into an char * array at well known
addresses. You can easily write this in a partable way.

If you are not interested in portability, you can use the gcc
extensions.

        Andrew

Re: [ECOS] data alignment issues

[Andrew Lunn]

On Thu, Aug 09, 2001 at 08:43:03AM -0600, Trenton D. Adams wrote:
> Why not send structures if it works?  After all, if I've tested it and
> there isn't any problems, then it's no problem right?  Is there any
> better way sending data?  I suppose I could send the structure one field
> at a time

What you are say is that it works today with gcc verions X for the
target, and MSVC version Y for the host. New version of the compilers
may decide to layout the structures differently. Borland may do
something different. The next versions of gcc may do something
different. MS may change there compiler. At that point, you have to
maintain old versions of the tools so you can rebuild your
application. 

What you should do is add some marshelling code. That takes the fields
from the structures and places them into an char * array at well known
addresses. You can easily write this in a partable way.

If you are not interested in portability, you can use the gcc
extensions.

        Andrew

RE: [ECOS] data alignment issues

[Trenton D. Adams]

Why not send structures if it works?  After all, if I've tested it and
there isn't any problems, then it's no problem right?  Is there any
better way sending data?  I suppose I could send the structure one field
at a time

I didn't mean I couldn't read a float in hex.  I mean I don't know how
it's stored in binary.  As in 00001000.10000000 would be 8.5, but I
don't know how this is stored in memory.  I know there aren't any two
byte floats, but that was just an example! :)

-----Original Message-----
From: ecos-discuss-owner@sources.redhat.com
[ mailto:ecos-discuss-owner@sources.redhat.com ] On Behalf Of
rob.wj.jansen@philips.com
Sent: Thursday, August 09, 2001 1:55 AM
To: tadams@theone.dnsalias.com
Cc: ecos-discuss@sources.redhat.com
Subject: Re: [ECOS] data alignment issues




> Any comments on this alignment?  I thought the gcc compiler didn't do 
> any alignment?

The compiler has to perform alignment since the ARM processor used will
only read 32 bit words on a 4 bytes boundary. As already written in one
of the previous posts, a fetch of a 32 bit words from a non aligned
boundary will result in an exception. To prevent any alignment problems,
gcc will align all members on a word boundary (which is a 4 byte
boundary for the ARM core).

> Anyhow, I just ran a test.  I have the structure below.  All the char 
> fields are just dummy values to test data alignment issues when 
> sending the structure over the network to my PC.  Apparently, the PC 
> compiler

You should never send structures to another platform in the hope that
the alignment of structures (and data widths of the members) are the
same. If both targets use the same alignment style and endianes this
might work, you could check this by populating a structure on both
targets in the same way and comparing the actual memory content.

> I've forgotten how to read floats in hex! :)

That what computers are for:

     float f = 10.0;

     if(sizeof(f) == 4)
          printf("Your float reads %08X in hex.\n", *(int *) &f);

(you C ...)

Regards,

     Rob Jansen

Software Engineer
Competence Center Platforms
BU Mobile Communications
Meijhorst 60-10, 6537 KT Nijmegen, The Netherlands
Tel: +31-24-353-6329
Fax: +31-24-353-3613
mailto:Rob.WJ.Jansen@philips.com

Re: [ECOS] data alignment issues

[rob.wj.jansen]

> Any comments on this alignment?  I thought the gcc compiler didn't do
> any alignment?

The compiler has to perform alignment since the ARM processor used will only read 32 bit words
on a 4 bytes boundary. As already written in one of the previous posts, a fetch of a 32 bit words
from a non aligned boundary will result in an exception.
To prevent any alignment problems, gcc will align all members on a word boundary (which is
a 4 byte boundary for the ARM core).

> Anyhow, I just ran a test.  I have the structure below.  All the char
> fields are just dummy values to test data alignment issues when sending
> the structure over the network to my PC.  Apparently, the PC compiler

You should never send structures to another platform in the hope that the alignment of structures
(and data widths of the members) are the same.
If both targets use the same alignment style and endianes this might work, you could check this
by populating a structure on both targets in the same way and comparing the actual memory content.

> I've forgotten how to read floats in hex! :)

That what computers are for:

     float f = 10.0;

     if(sizeof(f) == 4)
          printf("Your float reads %08X in hex.\n", *(int *) &f);

(you C ...)

Regards,

     Rob Jansen

Software Engineer
Competence Center Platforms
BU Mobile Communications
Meijhorst 60-10, 6537 KT Nijmegen, The Netherlands
Tel: +31-24-353-6329
Fax: +31-24-353-3613
mailto:Rob.WJ.Jansen@philips.com