Viewing the padded bytes

[Ben Bacarisse]

Which implementation?

The C compiler for the PERQ did this if memory serves, but it was a
long time ago.

 

[lawrence.jones]

Which implementation?

I don't recall. It may have been for the AT&T 3B.

 

[Alec S.]

You know, in all the discussion that has been going on in this thread, I did not
see anyone give one of the most obvious reason for caring about padding: games
development. Any console dev will tell you that it’s important to consider data
alignment and padding when designing your data, especially since you have a
particilar platform with specific specs to code for. Not only do you have a set
amount of memory to work with, but you can perform several kinds of
optimizations if the data is structured right. You can reduce the number of
reads, stream data faster, process data more efficiently, and some hardware even
requires certain alignments for some things.

I think I’ve seen the #pragma pack directive before, but another way to get some
control over alignment is with __declspec(align(x)).

Last month (December 2008)’s issue of Game Developer Mag had an article on just
this thing. Noel has provided an interesting pair of functions called
aligned_malloc and aligned_free that you can use to allocate and free variables
according to a specified alignment by controling (and automating) the padding.


I guess there aren’t any game devs here. :|

 

[Richard]

You know, in all the discussion that has been going on in this thread, I did not
see anyone give one of the most obvious reason for caring about padding: games
development. Any console dev will tell you that it’s important to consider data
alignment and padding when designing your data, especially since you have a
particilar platform with specific specs to code for. Not only do you have a set
amount of memory to work with, but you can perform several kinds of
optimizations if the data is structured right. You can reduce the number of
reads, stream data faster, process data more efficiently, and some hardware even
requires certain alignments for some things.

I think because when discussing alignment it was pretty obvious that the
alignment is done for a reason. The compiler and linked will take care
of things based on your pragmas/hints to best utilise the underlying HW.

I think I’ve seen the #pragma pack directive before, but another way to get some
control over alignment is with __declspec(align(x)).

Last month (December 2008)’s issue of Game Developer Mag had an article on just
this thing. Noel has provided an interesting pair of functions called
aligned_malloc and aligned_free that you can use to allocate and free variables
according to a specified alignment by controling (and automating) the padding.


I guess there aren’t any game devs here. :|

It is nothing specific to game development.

 

[Ian Collins]

You know, in all the discussion that has been going on in this thread, I did not
see anyone give one of the most obvious reason for caring about padding: games
development. Any console dev will tell you that it’s important to consider data
alignment and padding when designing your data, especially since you have a
particilar platform with specific specs to code for. Not only do you have a set
amount of memory to work with, but you can perform several kinds of
optimizations if the data is structured right. You can reduce the number of
reads, stream data faster, process data more efficiently, and some hardware even
requires certain alignments for some things.

That sounds like a general description of (particularly) embedded
development requirements!

I think I’ve seen the #pragma pack directive before, but another way to get some
control over alignment is with __declspec(align(x)).

On one of the cross posted platforms maybe, but not on others.

I guess there aren’t any game devs here. :|

Nothing in the OP's postings relate to alignment performance, they only
relate to his limited ability to visualise structure padding.

 

[Alec S.]

Ian Collins wrote (in

Nothing in the OP's postings relate to alignment performance, they only
relate to his limited ability to visualise structure padding.

True, but the disccusions that followed covered all kinds of padding-related
issues, with most people saying there’s no reason to care about it. As a matter
of fact, the OP’s issue of seeing the padding is probably quite easy. A couple
of casts have been provided that can do it. I guess this thread is a great
example of both discussions going off-topic, and serendipitous collabortaion.

 

[Alec S.]

Nathan Mates wrote (in

Unfortunately, C/C++ compilers are not allowed to dig into and
reorder your structs. After some years of development, or some
coworkers with an overactive sense of 'style' and grouping, a lot of
structs could be reduced in size. I'd love to have an (optional)
warning that'd say something like C###: struct has N bytes of padding,
but could be reordered to have only M padding bytes. Compilers are
treated as black boxes, but with a little bit of verbosity, useful
feedback can be generated.

I like that idea, and it could probably be fairly easy to implement as well.

(I have yet to receive this month’s GDM, but I think Noel mentioned reordering
struct members in the article.)

 

[swengineer001]

struct check_struct
{
double a;
char b;
char reserved[7];

};

If you do that you can see the padded bytes.
I don't think so. It will always show you the reserved member's

contents but I think the implementation is still free to insert
padding in any amount and at any location in this structure it
pleases, except at the beggining.<

I dare say, in principle, but I use compiler options which specify the
padding properties, and it would be unusual for 8 byte boundaries not to be
safe.

[I have large arrays of structures with many bit fields, and it is in my
interest, to arrange them so that padding is unnecessary, and so I control
very carefully where the bit fields fit in relation to byte and word
boundaries. It's a useful principle of "defensive programming".]

Dave

I agree that you using this with specific compiler options means you
will probably not have a problem but the OP question was how to view
the padding with no information about what options he is or is not
using and this may or may not give him what he wants. I too have used
this approach often and with no problems but you need to understand
your compiler which I am not sure if this is the case or not for the
OP. Given he did not just view the memory to see what the contents of
the padding are I would guess he is fairly new to this.

 

[Guest]

You know, in all the discussion that has been going on in this thread, I did not
see anyone give one of the most obvious reason for caring about padding: games
development. Any console dev will tell you that it’s important to consider data
alignment and padding when designing your data, especially since you have a
particilar platform with specific specs to code for. Not only do you have a set
amount of memory to work with, but you can perform several kinds of
optimizations if the data is structured right. You can reduce the number of
reads, stream data faster, process data more efficiently, and some hardware even
requires certain alignments for some things.

I think I’ve seen the #pragma pack directive before, but another way to get some
control over alignment is with __declspec(align(x)).

Last month (December 2008)’s issue of Game Developer Mag had an article on just
this thing. Noel has provided an interesting pair of functions called
aligned_malloc and aligned_free that you can use to allocate and free variables
according to a specified alignment by controling (and automating) the padding.

I guess there aren’t any game devs here. :|

I used the term "unless you're programming a toaster" as a shorthand
for any resource constrained embedded system. Eg. a toaster or
a games console.

I'm not disputing that you sometimes have to do tricks like this.
But you should use them when you need them. They should *not*
be your default coding style.

Even embedded code sometimes has to be surprisingly portable.
Those darn hardware engineers keep building new chips!


--
Nick Keighley

The beginning of wisdom for a [software engineer] is to recognize the
difference between getting a program to work, and getting it right.
-- M A Jackson, 1975

 

[Guest]

Nathan Mates wrote (innews:[email protected]):

I like that idea, and it could probably be fairly easy to implement as well.

I suspect you could implement it as a (nearly) standalone tool.
That is, I don't think you'd need a full syntax analysis of C.
But you would need some sort of code generation strategy configuration
to tell the tool how the compiler padded things.

<snip>

 

[Rainer Weikusat]

I used the term "unless you're programming a toaster" as a shorthand
for any resource constrained embedded system. Eg. a toaster or
a games console.

This doesn't make it any less nonsensical. Arranging struct members in
order to have them start at correctly aligned addresses without
compiler-inserted padding is a standard practice in kernel and network
programming. Actually, even formally specified binary communication
formats (supposed to be completely language-independent) often take
alignment issues into account. Aligning data to cacheline boundaries
is also a standard practice in code which needs to execute fastly. It
is even possible to do express this in a machine-independent way in
source code such that the compiled code will have the desired
properties.

[...]

Even embedded code sometimes has to be surprisingly portable.
Those darn hardware engineers keep building new chips!

Code which is written in the way I described above is often already
'surprisingly portable', eg Linux.

 

[Jacek Dziedzic]

Indeed, but it helps me know about it.

It could "help you know it" without compromising
portability, if you put your superfluous struct members
in a comment.

- J.

 

[Ben Voigt [C++ MVP]]

Of course, you are correct in suggesting that you should bare in mind

likely alignment restrictions when deciding on the order of fields and I
would agree with you that the following is BAD

struct bad {
double a;
char b;
double c;
}

Please explain what's bad about that (aside from the missing semicolon
following the type definition). Only in the unlikely circumstance that
sizeof (double) < sizeof (char).... and sizeof (char) is defined as 1 I'm
told. Any ordering of those three variables is likely to end up with sizeof
(bad) == 3 * sizeof (double) on architectures with alignment restrictions.

Interchange char and double and now you have an inefficient layout.

 

[Lew Pitcher]

Please explain what's bad about that (aside from the missing semicolon
following the type definition). Only in the unlikely circumstance that
sizeof (double) < sizeof (char).... and sizeof (char) is defined as 1 I'm
told. Any ordering of those three variables is likely to end up with
sizeof (bad) == 3 * sizeof (double) on architectures with alignment
restrictions.

Interchange char and double and now you have an inefficient layout.

With the given ordering, and an alignment requirement for the double
precision values, the compiler would have to insert padding after the char
element.

OTOH, with
struct alternative {
double a;
double c;
char b;
};
it is likely that no padding would be required after the char element.

Thus, the first ordering results in a structure that is larger than
necessary (as compared to the 2nd ordering).
--
Lew Pitcher

Master Codewright & JOAT-in-training | Registered Linux User #112576
http://pitcher.digitalfreehold.ca/ | GPG public key available by request
---------- Slackware - Because I know what I'm doing. ------

 

[James Kuyper]

Lew Pitcher wrote:
....

With the given ordering, and an alignment requirement for the double
precision values, the compiler would have to insert padding after the char
element.

OTOH, with
struct alternative {
double a;
double c;
char b;
};
it is likely that no padding would be required after the char element.

The structure size has to be a multiple of the alignment requirements of
any of it's members; otherwise members of the second element of an array
of "struct alternative" would be incorrectly aligned. Therefore, it
would still need padding.

 

[Måns Rullgård]

With the given ordering, and an alignment requirement for the double
precision values, the compiler would have to insert padding after the char
element.

OTOH, with
struct alternative {
double a;
double c;
char b;
};
it is likely that no padding would be required after the char element.

Thus, the first ordering results in a structure that is larger than
necessary (as compared to the 2nd ordering).

Not true. Structs are generally padded at the end to a multiple of
the alignment of the strictest element. If they were not, arrays
of structs would not work.

 

[Doug Harrison [MVP]]

OTOH, with
struct alternative {
double a;
double c;
char b;
};
it is likely that no padding would be required after the char element.

A double's worth of padding is required after the char in "alternative".
Otherwise, you could not have an array of "alternative".

 

[Keith Thompson]

[I'm temporarily not obeying the followup to comp.lang.c, since I'm
correcting an error that readers in the other newsgroup might be
interested in. I've redirected followups for this article to
comp.lang.c.]

[...]
With the given ordering, and an alignment requirement for the double
precision values, the compiler would have to insert padding after the char
element.

Conceivably it could move b to the end of the word and insert padding
before it; that's permitted, but unlikely.

OTOH, with
struct alternative {
double a;
double c;
char b;
};
it is likely that no padding would be required after the char element.

Thus, the first ordering results in a structure that is larger than
necessary (as compared to the 2nd ordering).

No, your "struct alternative" requires padding. The size of a
structure has to allow for arrays of that structure, and there are no
gaps between array elements. If you declare an array of two of these
structures:

struct alternative arr[2];

then arr[0].a, arr[0].b, arr[1].a, and arr[1].b must all be properly
aligned.

(This all assumes that double requires stricter alignment than char.)

 

[Måns Rullgård]

[I'm temporarily not obeying the followup to comp.lang.c, since I'm
correcting an error that readers in the other newsgroup might be
interested in. I've redirected followups for this article to
comp.lang.c.]

struct bad {
double a;
char b;
double c;
}

[...]
With the given ordering, and an alignment requirement for the double
precision values, the compiler would have to insert padding after the char
element.

Conceivably it could move b to the end of the word and insert padding
before it; that's permitted, but unlikely.

On a big-endian system without byte load/store instructions, this
would actually make sense. Cray T3D and early T3E are examples of
such systems.

 

[Flash Gordon]

Lew Pitcher wrote:
...

The structure size has to be a multiple of the alignment requirements of
any of it's members; otherwise members of the second element of an array
of "struct alternative" would be incorrectly aligned. Therefore, it
would still need padding.

I obviously forgot to put in the second char field at the end (I think
this was following from one of my posts, but I can't be certain since
Ben Voigt deleted the attributions.

struct fred {
double a;
char b;
double c;
char d;
};

Will on a lot of systems take up more memory than
struct blogs {
double a;
double c;
char b;
char d;
};

I'm not aware of any implementations where blogs would be larger than
fred. It is allowed by the C standard, but it is unlikely to occur in
the real world.