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
Struct alignment problem (GCC)
Started by ●April 8, 2008
Reply by ●April 9, 20082008-04-09
Reply by ●April 9, 20082008-04-09
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...
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
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...
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
Reply by ●April 9, 20082008-04-09
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
> 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
Reply by ●April 9, 20082008-04-09
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
>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
Reply by ●April 9, 20082008-04-09
Ralph Hempel Wrote
>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.
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 Enhanced email for the mobile individual based on Microsoft
Exchange - http://link.mail2web.com/Personal/EnhancedEmail
>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.
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 Enhanced email for the mobile individual based on Microsoft
Exchange - http://link.mail2web.com/Personal/EnhancedEmail
Reply by ●April 9, 20082008-04-09
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
>> 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
Reply by ●April 9, 20082008-04-09
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
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
Reply by ●April 9, 20082008-04-09
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...
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
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...
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
Reply by ●April 9, 20082008-04-09
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...
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
----- Original Message -----
From: s...@aeolusdevelopment.com
To: a...
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
Reply by ●April 9, 20082008-04-09
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... [mailto:A...] On Behalf Of
s...@aeolusdevelopment.com
Sent: Wednesday, April 09, 2008 11:12 AM
To: a...
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
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... [mailto:A...] On Behalf Of
s...@aeolusdevelopment.com
Sent: Wednesday, April 09, 2008 11:12 AM
To: a...
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
