Hi all,

I am generating my code with GNU-ARM..
I have searched and found that the solution to this struct mis-alignment problem is:
__attribute__((__packed__))

Is there any compiler option, that would do the same for all structs I define?
Or do I have to write this attribute to all of them?
I found in gcc.pdf

-fpack-struct
Pack all structure members together without holes.
Warning: the '-fpack-struct' switch causes GCC to generate code that is
not binary compatible with code generated without that switch. Additionally,
it makes the code suboptimal. Use it to conform to a non-default application
binary interface.
After compiling my code with this option, it did not work, which, I guess, confirms the warning.
I am not even sure if this is the correct compiler option.

Any help would be greatly appreciated..

Mit freundlichem Gruß / Best regards
Bekir ICLI



(You need to be a member of AT91SAM -- send a blank email to AT91SAM-subscribe@yahoogroups.com )

Foltos wrote:
> Hi,
>
> I think this will not work. Most compilers need the type modifier before
> the variable definition like:
> __packed struct foo {....};
> others need a #pragma on the line before the definition like:
> #pragma packed
> struct foo {...};

Which is why you might do something like this:

for GCC:

#define ATTPACKPRE
#define ATTPACKSUF __attribute__(__packed__))

for others:

#define ATTPACKPRE __packed
#define ATTPACKSUF

And your definition is:

ATTPACKPRE typedef struct {
int intvar;
...
} ATTPACKSUF structname;

Compilers that use #pragma should find another way since you cannot
easily use the c preprocessor to handle a #pragma in a #define....

Ralph
------------------------------------



(You need to be a member of AT91SAM -- send a blank email to AT91SAM-subscribe@yahoogroups.com )

Hi,

I think this will not work. Most compilers need the type modifier before
the variable definition like:
__packed struct foo {....};
others need a #pragma on the line before the definition like:
#pragma packed
struct foo {...};

If you want to get portable code, use 8 bit wide variable arrays, and
macro definitions to access elements. Example:
#define FRAME_LENGTH(fp) (fp[0] | (fp[1]<<8))
#define FRAME_SOMETHING32BIT_LE(fp) (fp[0] | (fp[1]<<8) |
(fp[2]<<16) | (fp[3]<<24) )
uint8_t frame[22];
uint16_t my_data=FRAME_LENGTH(frame);

Foltos

John wrote:
>
> Ditto the STRONG recommendation to avoid the global option.
>
> A while back, I had some compiler issues regarding pointers to packed
> vs. non-packed structures. The fix was to avoid the global option.
> You can do something like:
>
> #define PACKED_STRUCT __attribute__((__packed__))
>
> then you can use
>
> struct SomeStruct {...} PACKED_STRUCT;
>
> This way, if you switch to a different compiler, you re-define the
> PACKED_STRUCT to nothing and get rid of all the compiler warnings (or
> you can redefine it to whatever that particular compiler requires.)
>
> John
>
> --- In A...@yahoogroups.com ,
> "ICLI, Bekir (EXT)"
> wrote:
> >
> > Hi all,
> >
> > I am generating my code with GNU-ARM..
> > I have searched and found that the solution to this struct
> mis-alignment problem is:
> > __attribute__((__packed__))
> >
> > Is there any compiler option, that would do the same for all structs
> I define?
> > Or do I have to write this attribute to all of them?
> > I found in gcc.pdf
> >
> > -fpack-struct
> > Pack all structure members together without holes.
> > Warning: the '-fpack-struct' switch causes GCC to generate code that is
> > not binary compatible with code generated without that switch.
> Additionally,
> > it makes the code suboptimal. Use it to conform to a non-default
> application
> > binary interface.
> > After compiling my code with this option, it did not work, which, I
> guess, confirms the warning.
> > I am not even sure if this is the correct compiler option.
> >
> > Any help would be greatly appreciated..
> >
> > Mit freundlichem Gruß / Best regards
> > Bekir ICLI
> >



(You need to be a member of AT91SAM -- send a blank email to AT91SAM-subscribe@yahoogroups.com )

Ditto the STRONG recommendation to avoid the global option.

A while back, I had some compiler issues regarding pointers to packed
vs. non-packed structures. The fix was to avoid the global option.=20
You can do something like:

#define PACKED_STRUCT __attribute__((__packed__))

then you can use

struct SomeStruct {...} PACKED_STRUCT;

This way, if you switch to a different compiler, you re-define the
PACKED_STRUCT to nothing and get rid of all the compiler warnings (or
you can redefine it to whatever that particular compiler requires.)

John

--- In A...@yahoogroups.com, "ICLI, Bekir (EXT)"
wrote:
>
> Hi all,
>=20
> I am generating my code with GNU-ARM..
> I have searched and found that the solution to this struct
mis-alignment problem is:
> __attribute__((__packed__))
>=20
> Is there any compiler option, that would do the same for all structs
I define?
> Or do I have to write this attribute to all of them?
> I found in gcc.pdf
>=20
> -fpack-struct
> Pack all structure members together without holes.
> Warning: the '-fpack-struct' switch causes GCC to generate code that is
> not binary compatible with code generated without that switch.
Additionally,
> it makes the code suboptimal. Use it to conform to a non-default
application
> binary interface.
> After compiling my code with this option, it did not work, which, I
guess, confirms the warning.
> I am not even sure if this is the correct compiler option.
>=20
> Any help would be greatly appreciated..
>=20
> Mit freundlichem Gru=DF / Best regards
> Bekir ICLI
>

------------------------------------



(You need to be a member of AT91SAM -- send a blank email to AT91SAM-subscribe@yahoogroups.com )

Ralph Hempel schrieb:

> Compilers that use #pragma should find another way since you cannot
> easily use the c preprocessor to handle a #pragma in a #define....

Many compiler offer a pre-processor friendly way like __pragma()

--
42Bastian

Note: SPAM-only account, direct mail to bs42@...

------------------------------------



(You need to be a member of AT91SAM -- send a blank email to AT91SAM-subscribe@yahoogroups.com )

Ralph Hempel schrieb:

> 42Bastian wrote:
>> Ralph Hempel schrieb:
>>
>>> Compilers that use #pragma should find another way since you cannot
>>> easily use the c preprocessor to handle a #pragma in a #define....
>> Many compiler offer a pre-processor friendly way like __pragma()
>
> And for those compilers we are indeed grateful :-)

Amen.

--
42Bastian

Note: SPAM-only account, direct mail to bs42@...

------------------------------------



(You need to be a member of AT91SAM -- send a blank email to AT91SAM-subscribe@yahoogroups.com )

Hi,

i was working with a compiler (can't remember the chip and manufacturer)
which needed any special typecast after the type. Like this
static int __packed a;

I know this is really unusual but still I think the only portable
solution is to do it by hand (using macros).

Foltos

Ralph Hempel wrote:
>
> Foltos wrote:
> > Hi,
> >
> > I think this will not work. Most compilers need the type modifier
> before
> > the variable definition like:
> > __packed struct foo {....};
> > others need a #pragma on the line before the definition like:
> > #pragma packed
> > struct foo {...};
>
> Which is why you might do something like this:
>
> for GCC:
>
> #define ATTPACKPRE
> #define ATTPACKSUF __attribute__(__packed__))
>
> for others:
>
> #define ATTPACKPRE __packed
> #define ATTPACKSUF
>
> And your definition is:
>
> ATTPACKPRE typedef struct {
> int intvar;
> ...
> } ATTPACKSUF structname;
>
> Compilers that use #pragma should find another way since you cannot
> easily use the c preprocessor to handle a #pragma in a #define....
>
> Ralph
>
>



(You need to be a member of AT91SAM -- send a blank email to AT91SAM-subscribe@yahoogroups.com )

42Bastian wrote:
> Ralph Hempel schrieb:
>
>> Compilers that use #pragma should find another way since you cannot
>> easily use the c preprocessor to handle a #pragma in a #define....
>
> Many compiler offer a pre-processor friendly way like __pragma()

And for those compilers we are indeed grateful :-)

Ralph
------------------------------------



(You need to be a member of AT91SAM -- send a blank email to AT91SAM-subscribe@yahoogroups.com )

Foltos wrote:
> Hi,
>
> i was working with a compiler (can't remember the chip and manufacturer)
> which needed any special typecast after the type. Like this
> static int __packed a;
>
> I know this is really unusual but still I think the only portable
> solution is to do it by hand (using macros).

#define ATTPACKPRE __packed
#define ATTPACKSUF

static int ATTPACKPRE a ATTPACKSUF;

Still works and if you switch compilers you just change the macros

Ralph
------------------------------------



(You need to be a member of AT91SAM -- send a blank email to AT91SAM-subscribe@yahoogroups.com )

Hi,

you mean:
ATTPACKPRE static int ATTPACKPRESUF a ATTPACKSUF;

Yeah, looks really nice :)

/Foltos

Ralph Hempel wrote:
>
> Foltos wrote:
> > Hi,
> >
> > i was working with a compiler (can't remember the chip and
> manufacturer)
> > which needed any special typecast after the type. Like this
> > static int __packed a;
> >
> > I know this is really unusual but still I think the only portable
> > solution is to do it by hand (using macros).
>
> #define ATTPACKPRE __packed
> #define ATTPACKSUF
>
> static int ATTPACKPRE a ATTPACKSUF;
>
> Still works and if you switch compilers you just change the macros
>
> Ralph
>
>



(You need to be a member of AT91SAM -- send a blank email to AT91SAM-subscribe@yahoogroups.com )

Foltos Wrote
>i was working with a compiler (can't remember the chip and manufacturer)=20
>which needed any special typecast after the type. Like this
> static int __packed a;
>
>I know this is really unusual but still I think the only portable=20
>solution is to do it by hand (using macros).

Nah, the only truly portable solution is not to use any sort of packed
attribute. ;)

I've never run across a situation in which there wasn't a better solution
(especially with respect to portability) than using packed. Of course
better is somewhat in the eye of the beholder.

Packed is never necessary(1), I don't believe it's ever desirable.

Robert

1 - Except if you have to deal with a binary library built that way which
should be a rare circumstance on a microcontroller.

--------------------------------------------------------------------
mail2web LIVE =96 Free email based on Microsoft=AE Exchange technology -
http://link.mail2web.com/LIVE

------------------------------------



(You need to be a member of AT91SAM -- send a blank email to AT91SAM-subscribe@yahoogroups.com )

Well, maintaining compatibility with a binary database, or a filesystem, might be one example. Certainly in new code it makes a lot more sense to design structures so they align with natural boundaries.

I recently encountered IAR's lack of an inline packing directive. It offers a packing pragma which works fine, but I found no way to implement a macro equivalent to the per-variable packing possible with gcc. So much for portable code!

Chris

----- Original Message -----
From: s...@aeolusdevelopment.com
To: a...@yahoogroups.com
Sent: Wednesday, April 09, 2008 10:27 AM
Subject: Re: [AT91SAM] Re: Struct alignment problem (GCC)
Foltos Wrote
>i was working with a compiler (can't remember the chip and manufacturer)
>which needed any special typecast after the type. Like this
> static int __packed a;
>
>I know this is really unusual but still I think the only portable
>solution is to do it by hand (using macros).

Nah, the only truly portable solution is not to use any sort of packed
attribute. ;)

I've never run across a situation in which there wasn't a better solution
(especially with respect to portability) than using packed. Of course
better is somewhat in the eye of the beholder.

Packed is never necessary(1), I don't believe it's ever desirable.

Robert

1 - Except if you have to deal with a binary library built that way which
should be a rare circumstance on a microcontroller.

----------------------------------------------------------
mail2web LIVE - Free email based on Microsoft® Exchange technology -
http://link.mail2web.com/LIVE

------------------------------------------------------------------------------
No virus found in this incoming message.
Checked by AVG.
Version: 7.5.519 / Virus Database: 269.22.10/1367 - Release Date: 4/9/2008 7:10 AM



(You need to be a member of AT91SAM -- send a blank email to AT91SAM-subscribe@yahoogroups.com )

s...@aeolusdevelopment.com wrote:

> I've never run across a situation in which there wasn't a better solution
> (especially with respect to portability) than using packed. Of course
> better is somewhat in the eye of the beholder.

There may be one exception (really a trap) that I fell into once. We
had an application that happened to pack all structures on a 16 bit
micro. There was no real penalty for unaligned accesses in code
but they were a bit slower due to an extra fetch cycle.

Predictably, the micro or some supporting components were EOLed
and we upgraded to a Blackfin, where all accesses were aligned. Of
course, we had to be able to move data between the old and new
products.

Oh, and the same code base had to be used on both micros, so I
know a little bit about making the same code work for different
compilers :-)

We ended up going through all kinds of hoops to set up aligned
structures so that data could be exchanged before we figured out
that the problem was more general - the next mircro might
have blittle endian order and we were big endian here.

Long story short, we ended up with a little data description string
for each structure that had to transported across the wire, and a
routine that handled the interface between native structure access
and the packed wire protocol.

And I do use the packed attribute for my CDC code that runs on the
SAM7 and I'm not sure if I'd want to do it any other way...

Cheers, Ralph
------------------------------------



(You need to be a member of AT91SAM -- send a blank email to AT91SAM-subscribe@yahoogroups.com )

Chris DeLise Wrote
>Well, maintaining compatibility with a binary database, or a filesystem,
might be one >example.=20

Only at first blush I think.

>Certainly in new code it makes a lot more sense to design structures so
they align with >natural boundaries.

That, I believe to be fundamentally impossible. It assumes that your
current packing restrictions are the only or most sever ones you will
encounter. That's what got us into using packed to deal with binary files
to begin with :) Assuming a binary file is in fact the best method to be
using then the most portable way to do that is with cracking and packing
functions to break a byte stream into a structure or pack a structure into
a byte stream respectively. That not only deals with alignment but also
that other major bug-bear to file portability endianess. It also handles
some of the odder sizes that occasionally pop up.

Such cracking code will take no more space than what the compiler would
have had to generate anyway so there is no space saving to be had, and
resulting structures are naturally aligned leading to faster and smaller
code on alignment restricted micros. It has the advantage of being nearly
truly portable. No keyword fudging. I think the only real beast lurking in
the woods is the possibility that a char might be > 8 bits.

>I recently encountered IAR's lack of an inline packing directive. It
offers a packing >pragma which works fine, but I found no way to implement
a macro equivalent to the >per-variable packing possible with gcc. So much
for portable code!

Live by the pragma, die by the pragma :) Pragmas just provide a portable
way to be non-portable :)

Robert
--------------------------------------------------------------------
mail2web.com - Microsoft=AE Exchange solutions from a leading provider -
http://link.mail2web.com/Business/Exchange

------------------------------------



(You need to be a member of AT91SAM -- send a blank email to AT91SAM-subscribe@yahoogroups.com )

Ralph Hempel Wrote
>s...@aeolusdevelopment.com wrote:
>
>> I've never run across a situation in which there wasn't a better solutio=
n
>> (especially with respect to portability) than using packed. Of course
>> better is somewhat in the eye of the beholder.
>
>There may be one exception (really a trap) that I fell into once. We
>had an application that happened to pack all structures on a 16 bit
>micro. There was no real penalty for unaligned accesses in code
>but they were a bit slower due to an extra fetch cycle.

A very seductive trap.

>Predictably, the micro or some supporting components were EOLed
>and we upgraded to a Blackfin, where all accesses were aligned. Of
>course, we had to be able to move data between the old and new
>products.
>
>Oh, and the same code base had to be used on both micros, so I
>know a little bit about making the same code work for different
>compilers :-)
>
>We ended up going through all kinds of hoops to set up aligned
>structures so that data could be exchanged before we figured out
>that the problem was more general - the next mircro might
>have blittle endian order and we were big endian here.

That's what packing and cracking functions/macros are for. A good compiler
could make the transfer a simply copy on the original micro.

Besides little, big and middle endian orders, if you work across a network
like CAN you may have to deal with things like 5 and 18 bit integers. And
of course for some DSPs the natural integer is something like 24bits.

>Long story short, we ended up with a little data description string
>for each structure that had to transported across the wire, and a
>routine that handled the interface between native structure access
>and the packed wire protocol.

Duplicating (or anticipating) XDR ;)

>And I do use the packed attribute for my CDC code that runs on the
>SAM7 and I'm not sure if I'd want to do it any other way...

Why? It's only on the interfaces that it should be apparent and the code
will be faster and tighter internally then if they are not aligned. You'll
save a little space if the structures are a little messed up but that's it
I think(1).

Robert

1 - A perfect opportunity to correct the field order, I'm sure that's all
you need another opportunity ;)
--------------------------------------------------------------------
mail2web.com =96 Enhanced email for the mobile individual based on Microsof=
t=AE
Exchange - http://link.mail2web.com/Personal/EnhancedEmail

------------------------------------



(You need to be a member of AT91SAM -- send a blank email to AT91SAM-subscribe@yahoogroups.com )

s...@aeolusdevelopment.com wrote:

>> Long story short, we ended up with a little data description string
>> for each structure that had to transported across the wire, and a
>> routine that handled the interface between native structure access
>> and the packed wire protocol.
>
> Duplicating (or anticipating) XDR ;)

Yes, I did refer to the original Sun paper on this :-)

You would not believe (or maybe you would) the hoops I had to go
through to convince management that this was the correct thing
to do.

Ralph

------------------------------------



(You need to be a member of AT91SAM -- send a blank email to AT91SAM-subscribe@yahoogroups.com )

Ralph Hempel Wrote

s...@aeolusdevelopment.com wrote:

> Duplicating (or anticipating) XDR ;)
>
>Yes, I did refer to the original Sun paper on this :-)
>
>You would not believe (or maybe you would) the hoops I had to go
>through to convince management that this was the correct thing
>to do.

I can just about hear "but... can't you just do a quick patch..."

Robert

--------------------------------------------------------------------
mail2web.com =96 What can On Demand Business Solutions do for you?
http://link.mail2web.com/Business/SharePoint

------------------------------------



(You need to be a member of AT91SAM -- send a blank email to AT91SAM-subscribe@yahoogroups.com )

I had a recent situation where I was trying to port a large legacy codebase from gcc to IAR in a few hours, including a FAT32 filesystem and a variety of drivers for the MX21. The large number of structures with _packed syntax made it impossible to do in the time available. In retrospect, it was a little funny to think all of this open source code, and built in gcc, was totally non-portable.

I agree with Robert that accessor macros like NTOHS and NTOHL would have made childs play of this problem and far more portable than _packed. The network folks understand this, but there is a lot of legacy code that doesn't use these techniques. I think part of the problem is that ARM architecture doesn't gracefully cope with unaligned data in the way CISC machines do with reduced performance. An alignment fault would be a lot easier to cope with than forcing the compiler to flag misalignment. I wonder if anyone has created accessor macros that help with that.

Chris

----- Original Message -----
From: s...@aeolusdevelopment.com
To: A...@yahoogroups.com
Sent: Wednesday, April 09, 2008 11:28 AM
Subject: Re: [AT91SAM] Re: Struct alignment problem (GCC)
Chris DeLise Wrote
>Well, maintaining compatibility with a binary database, or a filesystem,
might be one >example.

Only at first blush I think.

>Certainly in new code it makes a lot more sense to design structures so
they align with >natural boundaries.

That, I believe to be fundamentally impossible. It assumes that your
current packing restrictions are the only or most sever ones you will
encounter. That's what got us into using packed to deal with binary files
to begin with :) Assuming a binary file is in fact the best method to be
using then the most portable way to do that is with cracking and packing
functions to break a byte stream into a structure or pack a structure into
a byte stream respectively. That not only deals with alignment but also
that other major bug-bear to file portability endianess. It also handles
some of the odder sizes that occasionally pop up.

Such cracking code will take no more space than what the compiler would
have had to generate anyway so there is no space saving to be had, and
resulting structures are naturally aligned leading to faster and smaller
code on alignment restricted micros. It has the advantage of being nearly
truly portable. No keyword fudging. I think the only real beast lurking in
the woods is the possibility that a char might be > 8 bits.

>I recently encountered IAR's lack of an inline packing directive. It
offers a packing >pragma which works fine, but I found no way to implement
a macro equivalent to the >per-variable packing possible with gcc. So much
for portable code!

Live by the pragma, die by the pragma :) Pragmas just provide a portable
way to be non-portable :)

Robert

----------------------------------------------------------
mail2web.com - Microsoft® Exchange solutions from a leading provider -
http://link.mail2web.com/Business/Exchange

------------------------------------------------------------------------------
No virus found in this incoming message.
Checked by AVG.
Version: 7.5.519 / Virus Database: 269.22.10/1367 - Release Date: 4/9/2008 7:10 AM



(You need to be a member of AT91SAM -- send a blank email to AT91SAM-subscribe@yahoogroups.com )

Yeah, I hear it every day. I remember a fellow consultant's old saw that you can have it fast, cheap, or right. Choose two. It seems there's never enough time to do it "right".

----- Original Message -----
From: s...@aeolusdevelopment.com
To: a...@yahoogroups.com
Sent: Wednesday, April 09, 2008 12:12 PM
Subject: Re: [AT91SAM] Re: Struct alignment problem (GCC)
Ralph Hempel Wrote

s...@aeolusdevelopment.com wrote:

> Duplicating (or anticipating) XDR ;)
>
>Yes, I did refer to the original Sun paper on this :-)
>
>You would not believe (or maybe you would) the hoops I had to go
>through to convince management that this was the correct thing
>to do.

I can just about hear "but... can't you just do a quick patch..."

Robert

----------------------------------------------------------
mail2web.com - What can On Demand Business Solutions do for you?
http://link.mail2web.com/Business/SharePoint

------------------------------------------------------------------------------
No virus found in this incoming message.
Checked by AVG.
Version: 7.5.519 / Virus Database: 269.22.10/1367 - Release Date: 4/9/2008 7:10 AM



(You need to be a member of AT91SAM -- send a blank email to AT91SAM-subscribe@yahoogroups.com )

Hi Guys,

I can't agree with Robert more about cracking and packing functions.

Worst case you have two functions you'll need to rewrite that are specific
to your target platform; one for cracking, one for packing.

The rest of the code that manipulates the data is the same.

Oh, and on the other subject of management and "quick patch"

As far as management is usually concerned "rewrite" should be a four letter
word.

No point in building the correct part when you have virtual duct tape handy.
;)

Dave

From: A...@yahoogroups.com [mailto:A...@yahoogroups.com] On Behalf Of
s...@aeolusdevelopment.com
Sent: Wednesday, April 09, 2008 11:12 AM
To: a...@yahoogroups.com
Subject: Re: [AT91SAM] Re: Struct alignment problem (GCC)

Ralph Hempel Wrote

s...@aeolusdevelopment.com
wrote:

> Duplicating (or anticipating) XDR ;)
>
>Yes, I did refer to the original Sun paper on this :-)
>
>You would not believe (or maybe you would) the hoops I had to go
>through to convince management that this was the correct thing
>to do.

I can just about hear "but... can't you just do a quick patch..."

Robert

----------------------------------------------------------
mail2web.com - What can On Demand Business Solutions do for you?
http://link.mail2web.com/Business/SharePoint



(You need to be a member of AT91SAM -- send a blank email to AT91SAM-subscribe@yahoogroups.com )

Chris DeLise wrote:
>
> The network folks understand this, but there is a lot of legacy code
> that doesn't use these techniques. I think part of the problem is that
> ARM architecture doesn't gracefully cope with unaligned data in the way
> CISC machines do with reduced performance.

This is the key point that a lot of "desktop" programmers don't get.

They have matured with PC technology where unaligned accesses of
data just take extra clock cycles, and where compilers generally
packed structure slements by default to save space.

They often don't understand that misaligned accesses are simply not
allowed on ARM (or Blackfin) devices - in fact just about any modern
micro that has some DSP aspirations has this "flaw" from their
point of view.

Even more surprising to them is that they compiler may not even
order their structure elements in the order they are defined!

Of course, us embedded old timers just grin when their carefully
crafted structures that mimic machine registers or network data
packets don't work as expected :-)

Ralph

PS. I love these types of threads as opposed to the "help me do
my homework" or "we need free drivers" messages

------------------------------------



(You need to be a member of AT91SAM -- send a blank email to AT91SAM-subscribe@yahoogroups.com )

Ralph,

> Even more surprising to them is that they compiler may not even
> order their structure elements in the order they are defined!

Actually, that is specifically precluded by the ISO standard: members *must*
be allocated in ascending address order.

--
Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
CrossWorks for ARM, MSP430, AVR, MAXQ, and now Cortex-M3 processors

------------------------------------



(You need to be a member of AT91SAM -- send a blank email to AT91SAM-subscribe@yahoogroups.com )

Paul Curtis wrote:
> Ralph,
>
>> Even more surprising to them is that they compiler may not even
>> order their structure elements in the order they are defined!
>
> Actually, that is specifically precluded by the ISO standard: members *must*
> be allocated in ascending address order.

You are, of course, correct. I was thinking of compiler directives
that allow structure members to be shuffled around to minimize
"wasted" space...

Thanks for pointing that out, and I'll keep it in my back pocket
for those often heated "why is the compiler doing THIS?" discussions.

Ralph

------------------------------------



(You need to be a member of AT91SAM -- send a blank email to AT91SAM-subscribe@yahoogroups.com )

> Nah, the only truly portable solution is not to use
> any sort of packed
> attribute. ;)
>
That's right!

Moreover there are cases where packed/alligned
attributes do not work as expected. For example I
wasn't able to make the following structure in 4 bytes
under gcc:

typedef union
{
struct {unsigned char low; unsigned char hi;};
unsigned short as_short;
} short_reg;

struct{
short_reg a ;
short_reg b ;
} test ;
I was using this with other compilers without
problems, but with gcc - no luck and I think I have
tried all...

__________________________________________________

------------------------------------



(You need to be a member of AT91SAM -- send a blank email to AT91SAM-subscribe@yahoogroups.com )

Just to make matters more interesting. I don't know which version of
GCC you are using, but I tried this:

//---------------------------------
struct hilo {unsigned char lo; unsigned char hi;};
typedef union
{
struct hilo highlow;
unsigned short as_short;
} short_reg;

struct {
short_reg a ;
short_reg b ;
} test ;

void main()
{
volatile int i;

test.a.highlow.hi=5;
test.a.highlow.lo=10;

i=test.a.highlow.hi*test.a.highlow.lo;

i=sizeof(test);

i=test.b.highlow.hi*2;
};
//---------------------------------

With CodeSourcery's command line compiler GCC 4.2.1, and the
sizeof(test) gives me 4.

John

--- In A...@yahoogroups.com, Miroslav Kostadinov wrote:
> > Nah, the only truly portable solution is not to use
> > any sort of packed
> > attribute. ;)
> >
> That's right!
>
> Moreover there are cases where packed/alligned
> attributes do not work as expected. For example I
> wasn't able to make the following structure in 4 bytes
> under gcc:
>
> typedef union
> {
> struct {unsigned char low; unsigned char hi;};
> unsigned short as_short;
> } short_reg;
>
> struct{
> short_reg a ;
> short_reg b ;
> } test ;
> I was using this with other compilers without
> problems, but with gcc - no luck and I think I have
> tried all...
>
> __________________________________________________

------------------------------------



(You need to be a member of AT91SAM -- send a blank email to AT91SAM-subscribe@yahoogroups.com )

John,

it's: arm-elf-gcc (GCC) 4.2.2 but I have noticed this
problem with earlier versions.

I guess you may have some "magic" command line
option... Here is my log:
Compiling C: app/main.c

arm-elf-gcc -c -mthumb -mcpu=arm7tdmi -gdwarf-2 -Os
-fomit-frame-pointer -fverbose-asm -I. -Wall
-Wcast-align -Wimplicit -Wstrict-prototypes
-Wpointer-arith -Wswitch -Wredundant-decls
-Wreturn-type -Wshadow -Wunused
-Wa,-adhlns=out/app/main.lst -Wnested-externs
-funsigned-char -std=gnu99 -MD -MP -MF
out/app/main.o.dep app/main.c -o out/app/main.o

--- John wrote:

> Just to make matters more interesting. I don't know
> which version of
> GCC you are using, but I tried this:
>
> //---------------------------------
> struct hilo {unsigned char lo; unsigned char hi;};
> typedef union
> {
> struct hilo highlow;
> unsigned short as_short;
> } short_reg;
>
> struct {
> short_reg a ;
> short_reg b ;
> } test ;
>
> void main()
> {
> volatile int i;
>
> test.a.highlow.hi=5;
> test.a.highlow.lo=10;
>
> i=test.a.highlow.hi*test.a.highlow.lo;
>
> i=sizeof(test);
>
> i=test.b.highlow.hi*2;
> };
> //---------------------------------
>
> With CodeSourcery's command line compiler GCC 4.2.1,
> and the
> sizeof(test) gives me 4.
>
> John
>
> --- In A...@yahoogroups.com, Miroslav Kostadinov
> wrote:
> >
> >
> > > Nah, the only truly portable solution is not to
> use
> > > any sort of packed
> > > attribute. ;)
> > >
> >
> >
> > That's right!
> >
> > Moreover there are cases where packed/alligned
> > attributes do not work as expected. For example I
> > wasn't able to make the following structure in 4
> bytes
> > under gcc:
> >
> > typedef union
> > {
> > struct {unsigned char low; unsigned char hi;};
> > unsigned short as_short;
> > } short_reg;
> >
> > struct{
> > short_reg a ;
> > short_reg b ;
> > } test ;
> >
> >
> > I was using this with other compilers without
> > problems, but with gcc - no luck and I think I
> have
> > tried all...
> >
> > __________________________________________________
> >
>

__________________________________________________

------------------------------------



(You need to be a member of AT91SAM -- send a blank email to AT91SAM-subscribe@yahoogroups.com )

arm-none-eabi-gcc -S testunion.c

Intermixing the resultant C and assembly code:
-------------------------------------------------
struct hilo {unsigned char lo; unsigned char hi;};

typedef union
{
struct hilo highlow;
unsigned short as_short;
} short_reg;

struct {
short_reg a ;
short_reg b ;
} test ;

void main()
{
volatile int i;

test.a.highlow.hi=5;
ldr r2, .L3
mov r3, #5
strb r3, [r2, #1]

test.a.highlow.lo=10;
ldr r2, .L3
mov r3, #10
strb r3, [r2, #0]

i=test.a.highlow.hi*test.a.highlow.lo;
ldr r3, .L3
ldrb r3, [r3, #1] @ zero_extendqisi2
mov r2, r3
ldr r3, .L3
ldrb r3, [r3, #0] @ zero_extendqisi2
mul r3, r2, r3
str r3, [fp, #-8]

i=sizeof(test);
mov r3, #4
str r3, [fp, #-8]

i=test.b.highlow.hi*2;
ldr r3, .L3
ldrb r3, [r3, #3] @ zero_extendqisi2
mov r3, r3, asl #1
str r3, [fp, #-8]
};
-------------------------------------------------
Again, looks right to me.

John

--- In A...@yahoogroups.com, Miroslav Kostadinov wrote:
>
> John,
>
> it's: arm-elf-gcc (GCC) 4.2.2 but I have noticed this
> problem with earlier versions.
>
> I guess you may have some "magic" command line
> option... Here is my log:
> Compiling C: app/main.c
>
> arm-elf-gcc -c -mthumb -mcpu=arm7tdmi -gdwarf-2 -Os
> -fomit-frame-pointer -fverbose-asm -I. -Wall
> -Wcast-align -Wimplicit -Wstrict-prototypes
> -Wpointer-arith -Wswitch -Wredundant-decls
> -Wreturn-type -Wshadow -Wunused
> -Wa,-adhlns=out/app/main.lst -Wnested-externs
> -funsigned-char -std=gnu99 -MD -MP -MF
> out/app/main.o.dep app/main.c -o out/app/main.o
>
> --- John wrote:
>
> > Just to make matters more interesting. I don't know
> > which version of
> > GCC you are using, but I tried this:
> >
> > //---------------------------------
> > struct hilo {unsigned char lo; unsigned char hi;};
> > typedef union
> > {
> > struct hilo highlow;
> > unsigned short as_short;
> > } short_reg;
> >
> > struct {
> > short_reg a ;
> > short_reg b ;
> > } test ;
> >
> > void main()
> > {
> > volatile int i;
> >
> > test.a.highlow.hi=5;
> > test.a.highlow.lo=10;
> >
> > i=test.a.highlow.hi*test.a.highlow.lo;
> >
> > i=sizeof(test);
> >
> > i=test.b.highlow.hi*2;
> > };
> > //---------------------------------
> >
> > With CodeSourcery's command line compiler GCC 4.2.1,
> > and the
> > sizeof(test) gives me 4.
> >
> > John
> >
> > --- In A...@yahoogroups.com, Miroslav Kostadinov
> > wrote:
> > >
> > >
> > > > Nah, the only truly portable solution is not to
> > use
> > > > any sort of packed
> > > > attribute. ;)
> > > >
> > >
> > >
> > > That's right!
> > >
> > > Moreover there are cases where packed/alligned
> > > attributes do not work as expected. For example I
> > > wasn't able to make the following structure in 4
> > bytes
> > > under gcc:
> > >
> > > typedef union
> > > {
> > > struct {unsigned char low; unsigned char hi;};
> > > unsigned short as_short;
> > > } short_reg;
> > >
> > > struct{
> > > short_reg a ;
> > > short_reg b ;
> > > } test ;
> > >
> > >
> > > I was using this with other compilers without
> > > problems, but with gcc - no luck and I think I
> > have
> > > tried all...
> > >
> > > __________________________________________________
> > >
> > >
> >
> >
> >
> __________________________________________________

------------------------------------



(You need to be a member of AT91SAM -- send a blank email to AT91SAM-subscribe@yahoogroups.com )

I just copy & paste your code in a new file named
testunion.c

And then I write in the command prompt:

arm-elf-gcc -S testunion.c

The resulting testunion.s file is:
.file "testunion.c"
.text
.align 2
.global main
.type main, %function
main:
@ args = 0, pretend = 0, frame = 4
@ frame_needed = 1, uses_anonymous_args = 0
mov ip, sp
stmfd sp!, {fp, ip, lr, pc}
sub fp, ip, #4
sub sp, sp, #4
ldr r2, .L3
mov r3, #5
strb r3, [r2, #1]
ldr r2, .L3
mov r3, #10
strb r3, [r2, #0]
ldr r3, .L3
ldrb r3, [r3, #1] @ zero_extendqisi2
mov r2, r3
ldr r3, .L3
ldrb r3, [r3, #0] @ zero_extendqisi2
mul r3, r2, r3
str r3, [fp, #-16]
mov r3, #8
str r3, [fp, #-16]
ldr r3, .L3
ldrb r3, [r3, #5] @ zero_extendqisi2
mov r3, r3, asl #1
str r3, [fp, #-16]
ldmfd sp, {r3, fp, sp, pc}
.L4:
.align 2
.L3:
.word test
.size main, .-main
.comm test,8,4
.ident "GCC: (GNU) 4.2.2"

I think we get almost "the same" result except for the
fact that the size is not the same ;-)

Cheers,
Miro

--- John wrote:

> arm-none-eabi-gcc -S testunion.c
>
> Intermixing the resultant C and assembly code:
> -------------------------------------------------
> struct hilo {unsigned char lo; unsigned char hi;};
>
> typedef union
> {
> struct hilo highlow;
> unsigned short as_short;
> } short_reg;
>
> struct {
> short_reg a ;
> short_reg b ;
> } test ;
>
> void main()
> {
> volatile int i;
>
> test.a.highlow.hi=5;
> ldr r2, .L3
> mov r3, #5
> strb r3, [r2, #1]
>
> test.a.highlow.lo=10;
> ldr r2, .L3
> mov r3, #10
> strb r3, [r2, #0]
>
> i=test.a.highlow.hi*test.a.highlow.lo;
> ldr r3, .L3
> ldrb r3, [r3, #1] @ zero_extendqisi2
> mov r2, r3
> ldr r3, .L3
> ldrb r3, [r3, #0] @ zero_extendqisi2
> mul r3, r2, r3
> str r3, [fp, #-8]
>
> i=sizeof(test);
> mov r3, #4
> str r3, [fp, #-8]
>
> i=test.b.highlow.hi*2;
> ldr r3, .L3
> ldrb r3, [r3, #3] @ zero_extendqisi2
> mov r3, r3, asl #1
> str r3, [fp, #-8]
> };
> -------------------------------------------------
> Again, looks right to me.
>
> John
>
> --- In A...@yahoogroups.com, Miroslav Kostadinov
> wrote:
> >
> > John,
> >
> > it's: arm-elf-gcc (GCC) 4.2.2 but I have noticed
> this
> > problem with earlier versions.
> >
> > I guess you may have some "magic" command line
> > option... Here is my log:
> >
> >
> > Compiling C: app/main.c
> >
> > arm-elf-gcc -c -mthumb -mcpu=arm7tdmi -gdwarf-2
> -Os
> > -fomit-frame-pointer -fverbose-asm -I. -Wall
> > -Wcast-align -Wimplicit -Wstrict-prototypes
> > -Wpointer-arith -Wswitch -Wredundant-decls
> > -Wreturn-type -Wshadow -Wunused
> > -Wa,-adhlns=out/app/main.lst -Wnested-externs
> > -funsigned-char -std=gnu99 -MD -MP -MF
> > out/app/main.o.dep app/main.c -o out/app/main.o
> >
> >
> >
> > --- John wrote:
> >
> > > Just to make matters more interesting. I don't
> know
> > > which version of
> > > GCC you are using, but I tried this:
> > >
> > > //---------------------------------
> > > struct hilo {unsigned char lo; unsigned char
> hi;};
> > > typedef union
> > > {
> > > struct hilo highlow;
> > > unsigned short as_short;
> > > } short_reg;
> > >
> > > struct {
> > > short_reg a ;
> > > short_reg b ;
> > > } test ;
> > >
> > > void main()
> > > {
> > > volatile int i;
> > >
> > > test.a.highlow.hi=5;
> > > test.a.highlow.lo=10;
> > >
> > > i=test.a.highlow.hi*test.a.highlow.lo;
> > >
> > > i=sizeof(test);
> > >
> > > i=test.b.highlow.hi*2;
> > > };
> > > //---------------------------------
> > >
> > > With CodeSourcery's command line compiler GCC
> 4.2.1,
> > > and the
> > > sizeof(test) gives me 4.
> > >
> > > John
> > >
> > > --- In A...@yahoogroups.com, Miroslav
> Kostadinov
> > > wrote:
> > > >
> > > >
> > > > > Nah, the only truly portable solution is not
> to
> > > use
> > > > > any sort of packed
> > > > > attribute. ;)
> > > > >
> > > >
> > > >
> > > > That's right!
> > > >
> > > > Moreover there are cases where packed/alligned
> > > > attributes do not work as expected. For
> example I
> > > > wasn't able to make the following structure in
> 4
> > > bytes
> > > > under gcc:
> > > >
> > > > typedef union
> > > > {
> > > > struct {unsigned char low; unsigned char
> hi;};
> > > > unsigned short as_short;
> > > > } short_reg;
> > > >
> > > > struct{
> > > > short_reg a ;
> > > > short_reg b ;
> > > > } test ;
> > > >
> > > >
> > > > I was using this with other compilers without
> > > > problems, but with gcc - no luck and I think I
> > > have
> > > > tried all...
> > > >
> > > >
> __________________________________________________
> > > >
> > > >
> > >
> > >
> > >
> >
> >
> > __________________________________________________
> >
>

__________________________________________________

------------------------------------



(You need to be a member of AT91SAM -- send a blank email to AT91SAM-subscribe@yahoogroups.com )

Hi all,

I've checked the history for my old question about using the "packed" attribute of gcc, and decided to follow it.
Here is my problem: We have a huge code in our project that is inherited from old projects and is written for a specific hardware.
And this code uses almost all the structs as packed. I have turned on the alignment error checks in MMU and am getting misaligned attempts almost all over the code.
My question is, is there any way to tell the compiler that he should handle all the code related to the packed structs only with byte-wise accesses ?? (no matter if it is byte, word, or double word access is)

PS: As you see, I am in such a desperate situation that I'd prefer functionality over performance in the first place, because the code is completely unknown to us and it'd take months to understand and manipulate it..

Regards,
Bekir

________________________________

Von: A...@yahoogroups.com [mailto:A...@yahoogroups.com] Im Auftrag von ICLI, Bekir (EXT)
Gesendet: Dienstag, 8. April 2008 09:48
An: A...@yahoogroups.com
Betreff: [AT91SAM] Struct alignment problem (GCC)

Hi all,

I am generating my code with GNU-ARM..
I have searched and found that the solution to this struct mis-alignment problem is:
__attribute__((__packed__))

Is there any compiler option, that would do the same for all structs I define?
Or do I have to write this attribute to all of them?
I found in gcc.pdf

-fpack-struct
Pack all structure members together without holes.
Warning: the '-fpack-struct' switch causes GCC to generate code that is
not binary compatible with code generated without that switch. Additionally,
it makes the code suboptimal. Use it to conform to a non-default application
binary interface.
After compiling my code with this option, it did not work, which, I guess, confirms the warning.
I am not even sure if this is the correct compiler option.

Any help would be greatly appreciated..

Mit freundlichem Gruß / Best regards
Bekir ICLI



(You need to be a member of AT91SAM -- send a blank email to AT91SAM-subscribe@yahoogroups.com )

ICLI, Bekir (EXT) schrieb:

> My question is, is there any way to tell the compiler that he should
> handle all the code related to the packed structs only with byte-wise
> accesses ?? (no matter if it is byte, word, or double word access is)

Maybe this option helps (size in bits!)
-mstructure-size-boundary=8
--
42Bastian

Note: SPAM-only account, direct mail to bs42@...

------------------------------------



(You need to be a member of AT91SAM -- send a blank email to AT91SAM-subscribe@yahoogroups.com )

Just be aware that if you use an option that affects the
structure packing, then your code is not binary compatible
with code that has been compiled without such an option.
i.e. you might have to recompile newlib with the same
option.

Regards
Anton Erasmus
On Mon, 21 Jul 2008 10:02:30 +0200
42Bastian wrote:
>ICLI, Bekir (EXT) schrieb:
>
>> My question is, is there any way to tell the compiler
>that he should
>> handle all the code related to the packed structs only
>with byte-wise
>> accesses ?? (no matter if it is byte, word, or double
>word access is)
>
>Maybe this option helps (size in bits!)
>-mstructure-size-boundary=8
>--
>42Bastian
>
>Note: SPAM-only account, direct mail to bs42@...
>
>------------------------------------



(You need to be a member of AT91SAM -- send a blank email to AT91SAM-subscribe@yahoogroups.com )

Hi,

Thanks for the answers..
I checked in GCC's "Using the GNU Compiler Collection" what "-ms.s.b=3D8" d=
oes.
There says:=20
" The size of all structures and unions will be rounded up to a multiple of=
the
number of bits set by this option. Permissible values are 8 and 32. The def=
ault
value varies for different toolchains. For the COFF targeted toolchain the =
default
value is 8. Specifying the larger number can produce faster, more efficient
code, but can also increase the size of the program. The two values are pot=
entially
incompatible. Code compiled with one value cannot necessarily expect
to work with code or libraries compiled with the other value, if they excha=
nge
information using structures or unions."

But my structs have no component smaller than a char, which is already 8 bi=
ts.
That means, giving this option should have no effect, am I right?=20

My problem is with the way the struct accesses are handled. I want to be ab=
le to tell the compiler to generate such a code that all write operations p=
erformed with these structs to be byte-per-byte.
PS: I have seen that the compiler uses for the 2byte write operations (of t=
he byte-packed structs) always byte-wise access. Coming from that, I though=
t it'd be possible to tell him, do this for 4 byte acesses as well.

Best regards,
Bekir

-----Urspr=FCngliche Nachricht-----
Von: A...@yahoogroups.com [mailto:A...@yahoogroups.com] Im Auftrag vo=
n Anton James Erasmus
Gesendet: Montag, 21. Juli 2008 10:51
An: A...@yahoogroups.com
Betreff: Re: [AT91SAM] Struct alignment problem (GCC)

Just be aware that if you use an option that affects the
structure packing, then your code is not binary compatible
with code that has been compiled without such an option.
i.e. you might have to recompile newlib with the same
option.

Regards
Anton Erasmus
On Mon, 21 Jul 2008 10:02:30 +0200
42Bastian wrote:
>ICLI, Bekir (EXT) schrieb:
>
>> My question is, is there any way to tell the compiler
>that he should
>> handle all the code related to the packed structs only
>with byte-wise
>> accesses ?? (no matter if it is byte, word, or double
>word access is)
>
>Maybe this option helps (size in bits!)
>-mstructure-size-boundary=3D8
>--=20
>42Bastian
>
>Note: SPAM-only account, direct mail to bs42@...
>
>------------------------------------



(You need to be a member of AT91SAM -- send a blank email to AT91SAM-subscribe@yahoogroups.com )

> But my structs have no component smaller than a char, which is already 8 bits.
> That means, giving this option should have no effect, am I right?

I used this option for TCP/IP where the IP header is misaligned due to
the 14 bytes of the ethernet-header.
It helped, gcc accesses long words byte by byte, until I rewrote the stack.

I'd say: Give it a try.

--
42Bastian

Note: SPAM-only account, direct mail to bs42@...

------------------------------------



(You need to be a member of AT91SAM -- send a blank email to AT91SAM-subscribe@yahoogroups.com )

I already did, but I can see in the resulting assembly code the 4byte acces=
ses.=20

-----Urspr=FCngliche Nachricht-----
Von: A...@yahoogroups.com [mailto:A...@yahoogroups.com] Im Auftrag vo=
n 42Bastian
Gesendet: Montag, 21. Juli 2008 11:34
An: A...@yahoogroups.com
Betreff: Re: AW: [AT91SAM] Struct alignment problem (GCC)
> But my structs have no component smaller than a char, which is already 8 =
bits.
> That means, giving this option should have no effect, am I right?=20

I used this option for TCP/IP where the IP header is misaligned due to=20
the 14 bytes of the ethernet-header.
It helped, gcc accesses long words byte by byte, until I rewrote the stack.

I'd say: Give it a try.

--=20
42Bastian

Note: SPAM-only account, direct mail to bs42@...

------------------------------------



(You need to be a member of AT91SAM -- send a blank email to AT91SAM-subscribe@yahoogroups.com )

ICLI, Bekir (EXT) schrieb:
> I already did, but I can see in the resulting assembly code the 4byte accesses.

Strange. I did a small test:
struct test {
int a;
int b;
int d;
} __attribute__((packed));

int a(struct test *p){
return p->a+p->d;
}

Compiled with: arm-thumb-elf-gcc -O -S
I get:
.file "t.c"
.text
.align 2
.global a
.type a, %function
a:
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
@ link register save eliminated.
@ lr needed for prologue
mov r3, r0
ldrb r1, [r0, #0] @ zero_extendqisi2
ldrb r2, [r0, #1] @ zero_extendqisi2
orr r1, r1, r2, asl #8
ldrb r2, [r0, #2] @ zero_extendqisi2
orr r1, r1, r2, asl #16
ldrb r2, [r0, #3] @ zero_extendqisi2
orr r1, r1, r2, asl #24
ldrb r0, [r0, #8] @ zero_extendqisi2
ldrb r2, [r3, #9] @ zero_extendqisi2
orr r0, r0, r2, asl #8
ldrb r2, [r3, #10] @ zero_extendqisi2
orr r0, r0, r2, asl #16
ldrb r3, [r3, #11] @ zero_extendqisi2
orr r0, r0, r3, asl #24
add r0, r1, r0
mov pc, lr
.size a, .-a
.ident "GCC: (GNU) 3.4.4"

--
42Bastian

Note: SPAM-only account, direct mail to bs42@...

------------------------------------



(You need to be a member of AT91SAM -- send a blank email to AT91SAM-subscribe@yahoogroups.com )

ICLI, Bekir (EXT) wrote:
> Hi all,

> My question is, is there any way to tell the compiler that he should
> handle all the code related to the packed structs only with byte-wise
> accesses ?? (no matter if it is byte, word, or double word access is)

Hmmmm, there are really two answers to this problem. The first has
already been suggested, and that is to force all structure members
to be aligned on word boundaries, but of course this does
not actually pack anything, and makes your structures bigger.

The way you have asked the question, I might assume that
some of the structures are being transmitted to the target
machine.

In this case, the only way around the problem is to write a library
that does the native to wire protocol pack/unpack operation for
you, and you'll have to design adescription string for every
structure.

I ran into this exact problem when porting code from an HC16 where
misaligned accesses were OK, to a Blackfin, where everything had to be
aligned on the correct boundary size.

Good luck!

Ralph

------------------------------------



(You need to be a member of AT91SAM -- send a blank email to AT91SAM-subscribe@yahoogroups.com )

Hi all,

I have another question related to this argument here.

Here is the declaration:

struct l2_apb apb;
struct l2_apb * l2_apb_ptr;

l2_apb is a struct which is defined with __attribute__(packed)

If I say:

l2_apb_ptr = &apb;

l2_apb_ptr->prev_blk_ptr = l_status;

where l_status (and prev_blk_ptr) are 2 byte variables, he handles it
with two byte-wise accesses (strb).

If I say:

apb.prev_blk_ptr = l_status;

He handles it with one word-wise access (strh). Which means, any time
when I work with a pointer to this struct, he handles all the accesses
byte-wise.
Can I have somehow any control over this behavior? Better asked, would
it be somehow possible to access to this variable word-wise with a
pointer?

Best Regards,
Bekir

________________________________

Von: A...@yahoogroups.com [mailto:A...@yahoogroups.com] Im Auftrag
von Ralph Hempel
Gesendet: Montag, 21. Juli 2008 14:31
An: A...@yahoogroups.com
Betreff: Re: [AT91SAM] Struct alignment problem (GCC)

ICLI, Bekir (EXT) wrote:
> Hi all,

> My question is, is there any way to tell the compiler that he should
> handle all the code related to the packed structs only with byte-wise
> accesses ?? (no matter if it is byte, word, or double word access is)

Hmmmm, there are really two answers to this problem. The first has
already been suggested, and that is to force all structure members
to be aligned on word boundaries, but of course this does
not actually pack anything, and makes your structures bigger.

The way you have asked the question, I might assume that
some of the structures are being transmitted to the target
machine.

In this case, the only way around the problem is to write a library
that does the native to wire protocol pack/unpack operation for
you, and you'll have to design adescription string for every
structure.

I ran into this exact problem when porting code from an HC16 where
misaligned accesses were OK, to a Blackfin, where everything had to be
aligned on the correct boundary size.

Good luck!

Ralph



(You need to be a member of AT91SAM -- send a blank email to AT91SAM-subscribe@yahoogroups.com )

Have you tried using:

__attribute__ ((aligned (2)))

rather than (packed)?

--- In A...@yahoogroups.com, "ICLI, Bekir (EXT)"
wrote:
>
> Hi all,
>
> I have another question related to this argument here.
>
> Here is the declaration:
>
> struct l2_apb apb;
> struct l2_apb * l2_apb_ptr;
>
> l2_apb is a struct which is defined with __attribute__(packed)
>
> If I say:
>
> l2_apb_ptr = &apb;
>
> l2_apb_ptr->prev_blk_ptr = l_status;
>
> where l_status (and prev_blk_ptr) are 2 byte variables, he handles it
> with two byte-wise accesses (strb).
>
> If I say:
>
> apb.prev_blk_ptr = l_status;
>
> He handles it with one word-wise access (strh). Which means, any time
> when I work with a pointer to this struct, he handles all the accesses
> byte-wise.
> Can I have somehow any control over this behavior? Better asked, would
> it be somehow possible to access to this variable word-wise with a
> pointer?
>
> Best Regards,
> Bekir
>
> ________________________________
>
> Von: A...@yahoogroups.com [mailto:A...@yahoogroups.com] Im Auftrag
> von Ralph Hempel
> Gesendet: Montag, 21. Juli 2008 14:31
> An: A...@yahoogroups.com
> Betreff: Re: [AT91SAM] Struct alignment problem (GCC)
>
> ICLI, Bekir (EXT) wrote:
> > Hi all,
>
> > My question is, is there any way to tell the compiler that he should
> > handle all the code related to the packed structs only with byte-wise
> > accesses ?? (no matter if it is byte, word, or double word access is)
>
> Hmmmm, there are really two answers to this problem. The first has
> already been suggested, and that is to force all structure members
> to be aligned on word boundaries, but of course this does
> not actually pack anything, and makes your structures bigger.
>
> The way you have asked the question, I might assume that
> some of the structures are being transmitted to the target
> machine.
>
> In this case, the only way around the problem is to write a library
> that does the native to wire protocol pack/unpack operation for
> you, and you'll have to design adescription string for every
> structure.
>
> I ran into this exact problem when porting code from an HC16 where
> misaligned accesses were OK, to a Blackfin, where everything had to be
> aligned on the correct boundary size.
>
> Good luck!
>
> Ralph
>

------------------------------------



(You need to be a member of AT91SAM -- send a blank email to AT91SAM-subscribe@yahoogroups.com )

ICLI, Bekir (EXT) wrote:
> Hi all,
>
> I have another question related to this argument here.
>
> Here is the declaration:
>
> struct l2_apb apb;
> struct l2_apb * l2_apb_ptr;
> l2_apb is a struct which is defined with __attribute__(packed)

First, avoid using lower case ell like this, it makes the
variable hard to read. (is that a 1 or an l?)

> If I say:
>
> l2_apb_ptr = &apb;
>
> l2_apb_ptr->prev_blk_ptr = l_status;
>
> where l_status (and prev_blk_ptr) are 2 byte variables, he handles it
> with two byte-wise accesses (strb).
>
> If I say:
>
> apb.prev_blk_ptr = l_status;
>
> He handles it with one word-wise access (strh). Which means, any time
> when I work with a pointer to this struct, he handles all the accesses
> byte-wise.
> Can I have somehow any control over this behavior? Better asked, would
> it be somehow possible to access to this variable word-wise with a pointer?

The answer is, it depends.

Actually you might need to answer another question first, which
is why are you trying to optimize this little bit of code? Is your
CPU or memory utilization so high that you're trying to save
instruction space and CPU cycles at the this level?

On to the answer you wanted :-)

When you define a structure as packed, the elements are jammed together
with no space, which is what you want. Note well that there may still
be endianness issues if you are shipping this struct off the CPU!

Individual instances of the structure are, however, aligned on natural
memory boundaries, which are 32 bits on the ARM. Depending on where
prev_blk_ptr is in the struct, the compiler might know that it can
safely do a word copy of l_status IF YOU ARE ADRESSING AN INDIVIDUAL
STRUCTURE INSTANCE.

Sorry for uppercasing, but that's an important point.

Once you access through a pointer, the compiler has no way of knowing
if the structure was aligned on a 32 bit boundary, because you might
have an l2_apb structure that is itself embedded in a packed structure.

So using the pointer access forces the compiler to use bye access
because it's simply safer.

To avoid this behaviour, don't pack your structures. It allows the
most efficient access to your structures.

And follow my advice from a previous message in this thread which
is to write a crack/uncrack library for the structures that you're
passing off the CPU :-)

Yes, I know it's a lot of work, but it will save you a lot of
debugging time later.

Ralph
------------------------------------



(You need to be a member of AT91SAM -- send a blank email to AT91SAM-subscribe@yahoogroups.com )