By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
424,961 Members | 1,333 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 424,961 IT Pros & Developers. It's quick & easy.

structures and alignment issues

P: n/a
struct a
{
int b;
char a;
int c;
}

On i386 the sizeof this structure would be 12 bytes,as 3 bytes are
padded after a so that c is aligned on 4byte boundary.

So the doubts that i have is

1) Does the poratbility issue come into play only when i persist this
structure on one architecture ( for ex i386) and try to read the
structure back on a different architecture(for ex motorola series)

Jun 14 '07 #1
Share this Question
Share on Google+
33 Replies


P: n/a
On Jun 14, 8:30 am, sil...@gmail.com wrote:
struct a
{
int b;
char a;
int c;

}

On i386 the sizeof this structure would be 12 bytes,as 3 bytes are
padded after a so that c is aligned on 4byte boundary.

So the doubts that i have is

1) Does the poratbility issue come into play only when i persist this
structure on one architecture ( for ex i386) and try to read the
structure back on a different architecture(for ex motorola series)
One more thing i want to get clarified is do all the compilers align
structure members using natural alignement or does this all differ
from architecture to architecture
Jun 14 '07 #2

P: n/a
si****@gmail.com wrote:
struct a
{
int b;
char a;
int c;
}

On i386 the sizeof this structure would be 12 bytes,as 3 bytes are
padded after a so that c is aligned on 4byte boundary.
That's one possible alignment.
So the doubts that i have is

1) Does the poratbility issue come into play only when i persist this
structure on one architecture ( for ex i386) and try to read the
structure back on a different architecture(for ex motorola series)
Or the same architecture with a different compiler, or the same compiler
with different options. Or...

--
Ian Collins.
Jun 14 '07 #3

P: n/a
si****@gmail.com wrote:

| 1) Does the poratbility issue come into play only when i persist
| this structure on one architecture ( for ex i386) and try to read
| the structure back on a different architecture(for ex motorola
| series)

No, it can always be an issue. Consider the differences in how a
single compiler on a single architecture might treat this structure
when told to optimize for speed vs when told to optimize for size...

--
Morris Dovey
DeSoto Solar
DeSoto, Iowa USA
http://www.iedu.com/DeSoto/
Jun 14 '07 #4

P: n/a

<si****@gmail.comwrote in message
news:11*********************@e9g2000prf.googlegrou ps.com...
On Jun 14, 8:30 am, sil...@gmail.com wrote:
>struct a
{
int b;
char a;
int c;

}

On i386 the sizeof this structure would be 12 bytes,as 3 bytes are
padded after a so that c is aligned on 4byte boundary.

So the doubts that i have is

1) Does the poratbility issue come into play only when i persist this
structure on one architecture ( for ex i386) and try to read the
structure back on a different architecture(for ex motorola series)

One more thing i want to get clarified is do all the compilers align
structure members using natural alignement or does this all differ
from architecture to architecture
Obviously compiler designers don't insert padding for fun. It is because
memory accesses to aligned members are more efficient. However it is always
possible and usually not very inefficient to access non-aligned members. The
question is where to make the trade off, and opinions differ.

Jun 14 '07 #5

P: n/a
On Jun 14, 10:23 am, "Malcolm McLean" <regniz...@btinternet.com>
wrote:
<sil...@gmail.comwrote in message

news:11*********************@e9g2000prf.googlegrou ps.com...
On Jun 14, 8:30 am, sil...@gmail.com wrote:
struct a
{
int b;
char a;
int c;
}
On i386 the sizeof this structure would be 12 bytes,as 3 bytes are
padded after a so that c is aligned on 4byte boundary.
So the doubts that i have is
1) Does the poratbility issue come into play only when i persist this
structure on one architecture ( for ex i386) and try to read the
structure back on a different architecture(for ex motorola series)
There should't be any issues if you use the structure name to
reference the members of it.
like struct_var.a, struct_var.b and so on. The byte padding is
transparent and the compiler will take care that when you get the same
value when you read struct_var.a as you would have stored using
struct_var.a = value.

But what the compiler doesn't gaurantee is that you take a pointer to
this struct and then try this

struct a * ptr = &struct_a_var;
int byte_padding = 3;
if( &struct_a_var.c == (ptr + sizeof(struct_a_var.a)
+sizeof(struct_a_var.b) + byte_padding))
{
.........
}

The above if condition may fail or may succeed and is really
architecture dependent and non-portable.

I have a piece of code which manipulates lt many strcutures and work
semalessly well whether it is run on intel or powerpc.

One more thing i want to get clarified is do all the compilers align
structure members using natural alignement or does this all differ
from architecture to architecture

This also differes from architecture to architecture. If an
architecture has faster access to memories on double word boundary
then the byte padding would be more. If the architecure has faster
access to addresses on byte boundaries then there will not be any
padding.

HTH.
----
Regards,
Taran

Jun 14 '07 #6

P: n/a
On Thu, 14 Jun 2007 03:30:03 -0000, in comp.lang.c , si****@gmail.com
wrote:
>struct a
{
int b;
char a;
int c;
}

On i386 the sizeof this structure would be 12 bytes,as 3 bytes are
padded after a so that c is aligned on 4byte boundary.

So the doubts that i have is

1) Does the poratbility issue come into play only when i persist this
structure on one architecture ( for ex i386) and try to read the
structure back on a different architecture(for ex motorola series)
No - even on one h/w platform you can see different padding depending
on compiler settings. See the FAQ for further discussion.
--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan
Jun 14 '07 #7

P: n/a
On Thu, 14 Jun 2007 03:34:25 -0000, in comp.lang.c , si****@gmail.com
wrote:
>One more thing i want to get clarified is do all the compilers align
structure members using natural alignement or does this all differ
from architecture to architecture
Its platform-dependent.
--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan
Jun 14 '07 #8

P: n/a
On Thu, 14 Jun 2007 00:09:06 -0700, in comp.lang.c , Taran
<ta************@gmail.comwrote:
>1) Does the poratbility issue come into play only when i persist this
structure on one architecture ( for ex i386) and try to read the
structure back on a different architecture(for ex motorola series)

There should't be any issues if you use the structure name to
reference the members of it.
Remember he is talking about persisting the data ie storing it to disk
or similar. When you read it back in, you will have to account for the
padding properly, in order to read in the data to the right members.
>I have a piece of code which manipulates lt many strcutures and work
semalessly well whether it is run on intel or powerpc.
Yes -it'll work fine provided you don't store binary data to disk,
copy the file to a different platform, and try to read it in again.

The FAQ talks about this in section 20.

--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan
Jun 14 '07 #9

P: n/a
si****@gmail.com wrote:
>
struct a
{
int b;
char a;
int c;
}

On i386 the sizeof this structure would be 12 bytes,as 3 bytes are
padded after a so that c is aligned on 4byte boundary.
Well, that's one possibility, but not the only one.
So the doubts that i have is

1) Does the poratbility issue come into play only when i persist this
structure on one architecture ( for ex i386) and try to read the
structure back on a different architecture(for ex motorola series)
Not only do you have to be concerned about padding, but byte order
as well. The i386 series is little-endian, and the Motorola chips
that I am familiar with are big-endian. Even if the compiler were
to use the same padding, the values of b and c won't be interpreted
the same way. For example, the i386 writes 1 as 01/00/00/00 which
will be seem by the big-endian CPU as 0x01000000, or 16,777,216.

BTDTGTTS.

I support a cross-platform database which writes such things to the
data file. (Please note that this app doesn't live in the strict C
world, but rather C plus POSIX plus some limited system-specific code
world.) While the source is 99% platform independent, the data files
are not, and a utility is included to massage the data from one
platform to another, should you wish to move the data files to
another system.

--
+-------------------------+--------------------+-----------------------+
| Kenneth J. Brody | www.hvcomputer.com | #include |
| kenbrody/at\spamcop.net | www.fptech.com | <std_disclaimer.h|
+-------------------------+--------------------+-----------------------+
Don't e-mail me at: <mailto:Th*************@gmail.com>
Jun 14 '07 #10

P: n/a
Malcolm McLean wrote:
<si****@gmail.comwrote in message
>On Jun 14, 8:30 am, sil...@gmail.com wrote:
>>struct a
{
int b;
char a;
int c;
}

On i386 the sizeof this structure would be 12 bytes,as 3 bytes
are padded after a so that c is aligned on 4byte boundary.

So the doubts that i have is

1) Does the poratbility issue come into play only when i persist
this structure on one architecture ( for ex i386) and try to
read the structure back on a different architecture(for ex
motorola series)

One more thing i want to get clarified is do all the compilers
align structure members using natural alignement or does this all
differ from architecture to architecture

Obviously compiler designers don't insert padding for fun. It is
because memory accesses to aligned members are more efficient.
However it is always possible and usually not very inefficient to
access non-aligned members. The question is where to make the
trade off, and opinions differ.
No the opinions don't differ. Unless the structure is to be read
ONLY by the identical program that wrote it, write it out field by
field in text. Also read it field by field.

--
<http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt>
<http://www.securityfocus.com/columnists/423>
<http://www.aaxnet.com/editor/edit043.html>
<http://kadaitcha.cx/vista/dogsbreakfast/index.html>
cbfalconer at maineline dot net

--
Posted via a free Usenet account from http://www.teranews.com

Jun 14 '07 #11

P: n/a
si****@gmail.com wrote:
>
struct a
{
int b;
char a;
int c;
}

On i386 the sizeof this structure would be 12 bytes,as 3 bytes are
padded after a so that c is aligned on 4byte boundary.

So the doubts that i have is

1) Does the poratbility issue come into play only when i persist this
structure on one architecture ( for ex i386) and try to read the
structure back on a different architecture(for ex motorola series)
Yes.

--
<http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt>
<http://www.securityfocus.com/columnists/423>
<http://www.aaxnet.com/editor/edit043.html>
<http://kadaitcha.cx/vista/dogsbreakfast/index.html>
cbfalconer at maineline dot net

--
Posted via a free Usenet account from http://www.teranews.com

Jun 14 '07 #12

P: n/a
On Thu, 14 Jun 2007 00:09:06 -0700, Taran <ta************@gmail.com>
wrote:
>On Jun 14, 10:23 am, "Malcolm McLean" <regniz...@btinternet.com>
wrote:
><sil...@gmail.comwrote in message

news:11*********************@e9g2000prf.googlegro ups.com...
On Jun 14, 8:30 am, sil...@gmail.com wrote:
struct a
{
int b;
char a;
int c;
>}
>On i386 the sizeof this structure would be 12 bytes,as 3 bytes are
padded after a so that c is aligned on 4byte boundary.
>So the doubts that i have is
>1) Does the poratbility issue come into play only when i persist this
structure on one architecture ( for ex i386) and try to read the
structure back on a different architecture(for ex motorola series)

There should't be any issues if you use the structure name to
reference the members of it.
like struct_var.a, struct_var.b and so on. The byte padding is
transparent and the compiler will take care that when you get the same
value when you read struct_var.a as you would have stored using
struct_var.a = value.

But what the compiler doesn't gaurantee is that you take a pointer to
this struct and then try this

struct a * ptr = &struct_a_var;
int byte_padding = 3;
if( &struct_a_var.c == (ptr + sizeof(struct_a_var.a)
+sizeof(struct_a_var.b) + byte_padding))
{
.........
}

The above if condition may fail or may succeed and is really
architecture dependent and non-portable.
The above condition is guaranteed to fail (actually evaluate to 0)
since pointer arithmetic is performed in units that match the sizeof
the object pointed to. ptr+1 is not the address of the second byte in
the structure but the address one byte beyond the end of the
structure.

If you cast the left expression to (char*) and change the right
expression to ((char*)ptr + ... + byte_padding) you at least have
something to discuss. If byte_padding is the sum of all the padding
prior to member c, why do you think the expression would ever be
false?
>
I have a piece of code which manipulates lt many strcutures and work
semalessly well whether it is run on intel or powerpc.

One more thing i want to get clarified is do all the compilers align
structure members using natural alignement or does this all differ
from architecture to architecture


This also differes from architecture to architecture. If an
architecture has faster access to memories on double word boundary
then the byte padding would be more. If the architecure has faster
access to addresses on byte boundaries then there will not be any
padding.
The compiler aligns members according to the way the compiler writer
decided it should. It may do it the way you describe. It may do it
some other way the compiler designer decided was more important (or
easier to implement or to simplify debugging etc). It may do it
differently depending on the options the user specified in that
particular run.

While most of us probably hope the compiler writer takes the
architecture into serious consideration when making these decisions,
he is not required to nor is he required to give the various aspects
of the architecture the same weight any of us would. It is entirely
possible for two compilers for the same architecture to do things
completely differently. It is even possible for different versions of
the same compiler to do it differently.
Remove del for email
Jun 14 '07 #13

P: n/a
Malcolm McLean <re*******@btinternet.comwrote:
Obviously compiler designers don't insert padding for fun. It is because
memory accesses to aligned members are more efficient. However it is always
possible and usually not very inefficient to access non-aligned members.
Always possible? I'm sure many folks who have had to deal with "bus
error" and its friends would beg to differ.

--
C. Benson Manica | I *should* know what I'm talking about - if I
cbmanica(at)gmail.com | don't, I need to know. Flames welcome.
Jun 14 '07 #14

P: n/a
In article <f4**********@chessie.cirr.com>,
Christopher Benson-Manica <at***@faeroes.freeshell.orgwrote:
>Obviously compiler designers don't insert padding for fun. It is because
memory accesses to aligned members are more efficient. However it is always
possible and usually not very inefficient to access non-aligned members.
>Always possible? I'm sure many folks who have had to deal with "bus
error" and its friends would beg to differ.
It's always possible for the implementation. However, it's likely to be
slower, even if the hardware has support for it.

-- Richard
--
"Consideration shall be given to the need for as many as 32 characters
in some alphabets" - X3.4, 1963.
Jun 14 '07 #15

P: n/a
Christopher Benson-Manica wrote:
>
Malcolm McLean <re*******@btinternet.comwrote:
Obviously compiler designers don't insert padding for fun. It is because
memory accesses to aligned members are more efficient. However it is always
possible and usually not very inefficient to access non-aligned members.

Always possible? I'm sure many folks who have had to deal with "bus
error" and its friends would beg to differ.
And for "not very inefficiently", I've used a system which would
allow you to access non-aligned values by catching the hardware
fault, reading the properly-aligned values containing the non-
aligned address you wanted, and (for read operations) extract the
bits you accessed, or (for write operations) store the bits you
were writing into the aligned values and write them back out.

--
+-------------------------+--------------------+-----------------------+
| Kenneth J. Brody | www.hvcomputer.com | #include |
| kenbrody/at\spamcop.net | www.fptech.com | <std_disclaimer.h|
+-------------------------+--------------------+-----------------------+
Don't e-mail me at: <mailto:Th*************@gmail.com>

Jun 14 '07 #16

P: n/a
Richard Tobin <ri*****@cogsci.ed.ac.ukwrote:
(MMcL wrote:)
Obviously compiler designers don't insert padding for fun. It is because
memory accesses to aligned members are more efficient. However it is always
possible and usually not very inefficient to access non-aligned members.
It's always possible for the implementation. However, it's likely to be
slower, even if the hardware has support for it.
I read the quoted text as "It is always possible for the implementor",
i.e. the developer (definitely not on the DS9K) or the compiler writer
(I would think that DS9K hardware could be sufficiently evil to
make it impossible). Of course anything is possible for the hardware
designer, and if that was what Malcolm actually intended I accept the
correction.

--
C. Benson Manica | I *should* know what I'm talking about - if I
cbmanica(at)gmail.com | don't, I need to know. Flames welcome.
Jun 14 '07 #17

P: n/a
In article <f4**********@chessie.cirr.com>,
Christopher Benson-Manica <at***@otaku.freeshell.orgwrote:
>Obviously compiler designers don't insert padding for fun. It is because
memory accesses to aligned members are more efficient. However it
is always
>possible and usually not very inefficient to access non-aligned members.
>It's always possible for the implementation. However, it's likely to be
slower, even if the hardware has support for it.
>I read the quoted text as "It is always possible for the implementor",
i.e. the developer (definitely not on the DS9K) or the compiler writer
(I would think that DS9K hardware could be sufficiently evil to
make it impossible).
Even on the DS9K it must be possible.

For example - and unfortunately I don't have the DS9K manual handy, so
I will use a fictitious machine - suppose we can only do 4-byte
aligned reads, but we want to read a 4-byte int at address 4n+1. Just
generate code to read the two ints at 4n and 4n+4 and extract and
combine the relevant bytes. I believe that some compilers on machines
with alignment restrictions have had the option to use just such code.

-- Richard
--
"Consideration shall be given to the need for as many as 32 characters
in some alphabets" - X3.4, 1963.
Jun 14 '07 #18

P: n/a
Richard Tobin wrote:
In article <f4**********@chessie.cirr.com>,
Christopher Benson-Manica <at***@otaku.freeshell.orgwrote:
>>Obviously compiler designers don't insert padding for fun. It is
because memory accesses to aligned members are more efficient.
However it
is always
>>possible and usually not very inefficient to access non-aligned
members.
>>It's always possible for the implementation. However, it's likely to be
slower, even if the hardware has support for it.
>>I read the quoted text as "It is always possible for the implementor",
i.e. the developer (definitely not on the DS9K) or the compiler writer
(I would think that DS9K hardware could be sufficiently evil to
make it impossible).

Even on the DS9K it must be possible.
Yes, even if the only possibility is to use memcpy() or equivalent, that's
one possibility.
For example - and unfortunately I don't have the DS9K manual handy, so
I will use a fictitious machine - suppose we can only do 4-byte
aligned reads, but we want to read a 4-byte int at address 4n+1. Just
generate code to read the two ints at 4n and 4n+4 and extract and
combine the relevant bytes. I believe that some compilers on machines
with alignment restrictions have had the option to use just such code.
That would read before the start and beyond the end of the object, which
causes problems, even if the machine words are partially accessible, on
some current real-world (debugging) implementations.
Jun 14 '07 #19

P: n/a
In article <f4***********@pc-news.cogsci.ed.ac.uk>,
Richard Tobin <ri*****@cogsci.ed.ac.ukwrote:
>In article <f4**********@chessie.cirr.com>,
Christopher Benson-Manica <at***@otaku.freeshell.orgwrote:
>>Obviously compiler designers don't insert padding for fun. It is because
memory accesses to aligned members are more efficient. However it
is always
>>possible and usually not very inefficient to access non-aligned members.
>Even on the DS9K it must be possible.
>For example - and unfortunately I don't have the DS9K manual handy, so
I will use a fictitious machine - suppose we can only do 4-byte
aligned reads, but we want to read a 4-byte int at address 4n+1. Just
generate code to read the two ints at 4n and 4n+4 and extract and
combine the relevant bytes.
If the data to be read is same width as the bus read size, but the
data is unaligned, then at least two bus reads would be necessary
to fetch the unaligned data. Unfortunately, when you use multiple
reads, you lose internal atomiticity, and by the time you get to
issue the second read, the second part of the data might have changed.
Or the first might have, leading you to write out the write sliced
result. It becomes a race condition, even if you don't have multiple
processors. And if you do have multiple processors... sometimes the
maximum coherency lock you can assert is for the maximum bus read size,
leading to problems.

But you should expect problems with this setup anyhow. To make this
clear: make the part that matches bus alignment volatile, so
issuing the extra read or write on the alignment boundary results in
undesirable behaviour.
--
"law -- it's a commodity"
-- Andrew Ryan (The Globe and Mail, 2005/11/26)
Jun 14 '07 #20

P: n/a
Richard Tobin <ri*****@cogsci.ed.ac.ukwrote:
For example - and unfortunately I don't have the DS9K manual handy, so
I will use a fictitious machine - suppose we can only do 4-byte
aligned reads, but we want to read a 4-byte int at address 4n+1. Just
generate code to read the two ints at 4n and 4n+4 and extract and
combine the relevant bytes. I believe that some compilers on machines
with alignment restrictions have had the option to use just such code.
Aha, yes, I suppose I should have thought of that, although I imagine
it adds another couple of espressos to the lives of compiler
implementors. Thanks for the answer.

--
C. Benson Manica | I *should* know what I'm talking about - if I
cbmanica(at)gmail.com | don't, I need to know. Flames welcome.
Jun 14 '07 #21

P: n/a
"Harald van Dijk" <tr*****@gmail.comwrote in message
news:f4**********@news5.zwoll1.ov.home.nl...
Richard Tobin wrote:
>For example - and unfortunately I don't have the DS9K manual
handy, so I will use a fictitious machine - suppose we can only
do 4-byte aligned reads, but we want to read a 4-byte int at
address 4n+1. Just generate code to read the two ints at 4n
and 4n+4 and extract and combine the relevant bytes. I believe
that some compilers on machines with alignment restrictions
have had the option to use just such code.

That would read before the start and beyond the end of the object,
which causes problems, even if the machine words are partially
accessible, on some current real-world (debugging)
implementations.
It's UB to do that in C, but it's entirely possible (and highly likely) that
the implementation can that under the hood safely. Code the compiler emits
is only subject to the rules the architecture sets, not the C standard.

S

--
Stephen Sprunk "Those people who think they know everything
CCIE #3723 are a great annoyance to those of us who do."
K5SSS --Isaac Asimov
--
Posted via a free Usenet account from http://www.teranews.com

Jun 15 '07 #22

P: n/a
<si****@gmail.comwrote in message
news:11**********************@q19g2000prn.googlegr oups.com...
struct a
{
int b;
char a;
int c;
}

On i386 the sizeof this structure would be 12 bytes,as 3 bytes are
padded after a so that c is aligned on 4byte boundary.
No, on your particular implementation it's 12 bytes. On other
implementations (including the same compiler with different flags) it may be
another value. In particular, 6 and 24 are ones you're likely to see, but
there are other possibilities as well, even on x86 machines.
So the doubts that i have is
That's a question, not a doubt.
1) Does the poratbility issue come into play only when i persist this
structure on one architecture ( for ex i386) and try to read the
structure back on a different architecture(for ex motorola series)
If you mean write the structure to a file as a single binary object, then
try to read it as a structure on another implementation, that will cause you
a world of headaches in the real world. The sizes, padding, and
representation (including endianness in particular) of those types can all
vary by implementation.

The C FAQ covers all of this. Please go read it.

S

--
Stephen Sprunk "Those people who think they know everything
CCIE #3723 are a great annoyance to those of us who do."
K5SSS --Isaac Asimov
--
Posted via a free Usenet account from http://www.teranews.com

Jun 15 '07 #23

P: n/a
"Stephen Sprunk" <st*****@sprunk.orgwrites:
"Harald van Dijk" <tr*****@gmail.comwrote in message
news:f4**********@news5.zwoll1.ov.home.nl...
>Richard Tobin wrote:
>>For example - and unfortunately I don't have the DS9K manual
handy, so I will use a fictitious machine - suppose we can only
do 4-byte aligned reads, but we want to read a 4-byte int at
address 4n+1. Just generate code to read the two ints at 4n
and 4n+4 and extract and combine the relevant bytes. I believe
that some compilers on machines with alignment restrictions
have had the option to use just such code.

That would read before the start and beyond the end of the object,
which causes problems, even if the machine words are partially
accessible, on some current real-world (debugging)
implementations.

It's UB to do that in C, but it's entirely possible (and highly
likely) that the implementation can that under the hood safely. Code
the compiler emits is only subject to the rules the architecture sets,
not the C standard.
Yes, but I suspect that solution won't work on the DS9K. Doing the
equivalent of memcpy(), however, will.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Jun 15 '07 #24

P: n/a
On 14 Jun 2007 17:05:22 GMT, in comp.lang.c , ri*****@cogsci.ed.ac.uk
(Richard Tobin) wrote:
>In article <f4**********@chessie.cirr.com>,
Christopher Benson-Manica <at***@faeroes.freeshell.orgwrote:
>>Obviously compiler designers don't insert padding for fun. It is because
memory accesses to aligned members are more efficient. However it is always
possible and usually not very inefficient to access non-aligned members.
>>Always possible? I'm sure many folks who have had to deal with "bus
error" and its friends would beg to differ.

It's always possible for the implementation. However, it's likely to be
slower, even if the hardware has support for it.
It may not always be possible. Some hardware simply won't let you
create misaligned objects.
--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan
Jun 15 '07 #25

P: n/a
In article <a3********************************@4ax.com>,
Mark McIntyre <ma**********@spamcop.netwrote:
>>It's always possible for the implementation. However, it's likely to be
slower, even if the hardware has support for it.
>It may not always be possible. Some hardware simply won't let you
create misaligned objects.
See the rest of the thread. It could access misaligned objects as
bytes, or by bit operations on larger, aligned objects. C's virtual
machine accesses don't have to correspond directly to hardware
accesses.

-- Richard
--
"Consideration shall be given to the need for as many as 32 characters
in some alphabets" - X3.4, 1963.
Jun 15 '07 #26

P: n/a
On 15 Jun 2007 14:26:09 GMT, in comp.lang.c , ri*****@cogsci.ed.ac.uk
(Richard Tobin) wrote:
>In article <a3********************************@4ax.com>,
Mark McIntyre <ma**********@spamcop.netwrote:
>>>It's always possible for the implementation. However, it's likely to be
slower, even if the hardware has support for it.
>>It may not always be possible. Some hardware simply won't let you
create misaligned objects.

See the rest of the thread. It could access misaligned objects as
bytes, or by bit operations on larger, aligned objects.
Yeah, but if you can't /create/ a misaligned object?
>C's virtual
machine accesses don't have to correspond directly to hardware
accesses.
If you chop the middle 8 bits out of a 32-bit word by using some
bitshifting trickery, you have not accessed a misaligned object, IMHO.
--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan
Jun 15 '07 #27

P: n/a
In article <ll********************************@4ax.com>,
Mark McIntyre <ma**********@spamcop.netwrote:
>>See the rest of the thread. It could access misaligned objects as
bytes, or by bit operations on larger, aligned objects.
>Yeah, but if you can't /create/ a misaligned object?
The question is about how an implementation can align objects.
>If you chop the middle 8 bits out of a 32-bit word by using some
bitshifting trickery, you have not accessed a misaligned object, IMHO.
If your definition of misaligned is that you can't access it, then
obviously you can't access one. The point is that on a system where
the instruction set architecture imposes alignment restrictions, a C
implementation can still place objects at addresses not in accord with
that alignment, provided it generates code to read and write the
objects in ways that the system allows.

This is not unrealistic: a system that allows "packed" structures
(perhaps by means of a pragma) might well use such a technique.

-- Richard
--
"Consideration shall be given to the need for as many as 32 characters
in some alphabets" - X3.4, 1963.
Jun 15 '07 #28

P: n/a
Mark McIntyre <ma**********@spamcop.netwrites:
On 15 Jun 2007 14:26:09 GMT, in comp.lang.c , ri*****@cogsci.ed.ac.uk
(Richard Tobin) wrote:
>>In article <a3********************************@4ax.com>,
Mark McIntyre <ma**********@spamcop.netwrote:
>>>>It's always possible for the implementation. However, it's likely to be
slower, even if the hardware has support for it.
>>>It may not always be possible. Some hardware simply won't let you
create misaligned objects.

See the rest of the thread. It could access misaligned objects as
bytes, or by bit operations on larger, aligned objects.

Yeah, but if you can't /create/ a misaligned object?
[...]

The implementation can always create a misaligned object. An "object"
is a construct of the C implementation, not of the underlying
hardware. In the worst case, the compiler can generate code to
memcpy() the misaligned object's contents into an aligned object,
operate on the aligned object, and then memcpy() the contents back
again.

I don't believe there are any circumstances in which "you can't
/create/ a misaligned object". Can you provide an example of what you
mean?

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Jun 15 '07 #29

P: n/a
Keith Thompson wrote On 06/15/07 15:51,:
Mark McIntyre <ma**********@spamcop.netwrites:
>>
Yeah, but if you can't /create/ a misaligned object?

[...]

The implementation can always create a misaligned object. [...]
Even on a machine where char-alignment suffices for
all types? My beloved old Z80 box was such an one ...

--
Er*********@sun.com
Jun 15 '07 #30

P: n/a
In article <1181939249.87102@news1nwk>,
Eric Sosman <Er*********@Sun.COMwrote:
>The implementation can always create a misaligned object. [...]
Even on a machine where char-alignment suffices for
all types?
Fair enough...
>My beloved old Z80 box was such an one ...
x86 machines are still like that, but they're slower with misaligned
data (because they fetch aligned words from memory).

Of course, you need not align things even on byte boundaries, but
you'd have to consider how to represent the addresses.

-- Richard

--
"Consideration shall be given to the need for as many as 32 characters
in some alphabets" - X3.4, 1963.
Jun 15 '07 #31

P: n/a
On Fri, 15 Jun 2007 12:51:29 -0700, in comp.lang.c , Keith Thompson
<ks***@mib.orgwrote:
>Mark McIntyre <ma**********@spamcop.netwrites:
>On 15 Jun 2007 14:26:09 GMT, in comp.lang.c , ri*****@cogsci.ed.ac.uk
(Richard Tobin) wrote:
>>>In article <a3********************************@4ax.com>,
Mark McIntyre <ma**********@spamcop.netwrote:
>It's always possible for the implementation. However, it's likely to be
>slower, even if the hardware has support for it.

It may not always be possible. Some hardware simply won't let you
create misaligned objects.

See the rest of the thread. It could access misaligned objects as
bytes, or by bit operations on larger, aligned objects.

Yeah, but if you can't /create/ a misaligned object?
[...]

The implementation can always create a misaligned object.
I believe someone has already disproved that elsethread!
An "object"
is a construct of the C implementation, not of the underlying
hardware.
Sure. However if the h/w won't point at any non-divisible-by-N
boundary, then you can't create a misaligned object.

--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan
Jun 15 '07 #32

P: n/a
Eric Sosman wrote:
Keith Thompson wrote On 06/15/07 15:51,:
>Mark McIntyre <ma**********@spamcop.netwrites:
>>Yeah, but if you can't /create/ a misaligned object?
[...]

The implementation can always create a misaligned object. [...]

Even on a machine where char-alignment suffices for
all types? My beloved old Z80 box was such an one ...
Indeed. Something about 8-bit data bus I'd guess. :-)

--
Joe Wright
"Everything should be made as simple as possible, but not simpler."
--- Albert Einstein ---
Jun 16 '07 #33

P: n/a
Mark McIntyre <ma**********@spamcop.netwrites:
On Fri, 15 Jun 2007 12:51:29 -0700, in comp.lang.c , Keith Thompson
<ks***@mib.orgwrote:
>>Mark McIntyre <ma**********@spamcop.netwrites:
>>On 15 Jun 2007 14:26:09 GMT, in comp.lang.c , ri*****@cogsci.ed.ac.uk
(Richard Tobin) wrote:
In article <a3********************************@4ax.com>,
Mark McIntyre <ma**********@spamcop.netwrote:
>>It's always possible for the implementation. However, it's likely to be
>>slower, even if the hardware has support for it.

>It may not always be possible. Some hardware simply won't let you
>create misaligned objects.

See the rest of the thread. It could access misaligned objects as
bytes, or by bit operations on larger, aligned objects.

Yeah, but if you can't /create/ a misaligned object?
[...]

The implementation can always create a misaligned object.

I believe someone has already disproved that elsethread!
Sure, if there's no such thing as a misaligned object, then you can't
create one. But ...
>An "object" is a construct of the C implementation, not of the
underlying hardware.

Sure. However if the h/w won't point at any non-divisible-by-N
boundary, then you can't create a misaligned object.
Not true. Consider a Cray vector system, where hardware addresses can
only point to 64-bit words. The C compiler creates, purely in
software, a pointer representation that it uses to access 8-bit bytes.
More generally, if the hardware can't point to something, the software
can.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Jun 16 '07 #34

This discussion thread is closed

Replies have been disabled for this discussion.