P142 K&R

[mdh]

The 3rd paragraph says: "Alignment requirements can generally be
satisfied easily, at the cost of some wasted space, by ensuring that
the allocator always return a poiner that meets all ( italicized)
alignment restrictions"

I have looked at the threads about alignment in this group, and most
**assume** that the writer/replies understand fully what alignment
entails. There are some quite good explanations on the web, but none
really capture for me, at least, the essence of what alignment does,
and what can go wrong if alignment is not adhered to.

So, could anyone very very briefly explain the essence of alignment
and why the C programmer should worry about it and why it seems to
come up in structs and pointers..(if this last fact is indeed
true). .

Thanks as usual.

 

[Tim Prince]

The 3rd paragraph says: "Alignment requirements can generally be
satisfied easily, at the cost of some wasted space, by ensuring that
the allocator always return a poiner that meets all ( italicized)
alignment restrictions"

I have looked at the threads about alignment in this group, and most
**assume** that the writer/replies understand fully what alignment
entails. There are some quite good explanations on the web, but none
really capture for me, at least, the essence of what alignment does,
and what can go wrong if alignment is not adhered to.

So, could anyone very very briefly explain the essence of alignment
and why the C programmer should worry about it and why it seems to
come up in structs and pointers..(if this last fact is indeed
true). .

Thanks as usual.

No, this is not a brief subject. I'll try to compromise.
Most platforms have either a performance penalty or throw an address fault
upon misaligned access. Aligned addresses are those which are a multiple
of the size of the object (16 bytes for 128-bit parallel objects on
several platforms).
"64-bit" systems usually default to alignments which don't cause serious
problems. "32-bit" systems default to alignments which are problematical
for objects wider than int (or, wider than double, or long int, as the
case may be), in part because of the frequent need to conserve stack space.
structs involve no end of alignment problems, unless a rule is followed of
setting the fields in order of decreasing size, avoiding options which
affect alignment, and avoiding mixing compilers.

 

[Keith Thompson]

The 3rd paragraph says: "Alignment requirements can generally be
satisfied easily, at the cost of some wasted space, by ensuring that
the allocator always return a poiner that meets all ( italicized)
alignment restrictions"

I have looked at the threads about alignment in this group, and most
**assume** that the writer/replies understand fully what alignment
entails. There are some quite good explanations on the web, but none
really capture for me, at least, the essence of what alignment does,
and what can go wrong if alignment is not adhered to.

So, could anyone very very briefly explain the essence of alignment
and why the C programmer should worry about it and why it seems to
come up in structs and pointers..(if this last fact is indeed
true). .

The C99 standard actually has a definition of the word "alignment":

alignment

requirement that objects of a particular type be located on
storage boundaries with addresses that are particular multiples of
a byte address

Though it doesn't say what it means for an address to be a "multiple"
of something.

 

[mdh]

No, this is not a brief subject.

I was hoping

 I'll try to compromise.
Most platforms have either a performance penalty or throw an address fault
upon misaligned access.  Aligned addresses are those which are a multiple
of the size of the object (16 bytes for 128-bit parallel objects on
several platforms).
"64-bit" systems usually default to alignments which don't cause serious
problems.  "32-bit" systems default to alignments which are problematical
for objects wider than int (or, wider than double, or long int, as the
case may be), in part because of the frequent need to conserve stack space.
structs involve no end of alignment problems, unless a rule is followed.....

Is it correct to assume structs involve problems as these are user
defined and thus could be made up of any number of objects? And if
this is true, is it up to the programmer to take into account the ?
order of objects in a struct?

 

[mdh]

mdh said:



It's more that they could be made up of any *sizes* of objects.


Given the importance of getting alignment right, it is a curious fact that,
IF you follow all the other rules of C, you don't actually have to
understand alignment at all! It obviously won't hurt, and it will give you
a broader understanding of the issues underlying some of C's rules, but
it's not actually essential.

And it's certainly not necessary to worry about the order of the objects in
a struct if you're not likely to run short of "stack space". I've never
been in a position where I had to be concerned about this, even on
relatively small systems such as Ataris and 8086s (but yes, there are even
smaller systems out there, so it's not impossible that you'll hit that
issue one day).

thank you.

 

[mdh]

The C99 standard actually has a definition of the word "alignment":

    alignment

    requirement that objects of a particular type be located on
    storage boundaries with addresses that are particular multiples of
    a byte address

Though it doesn't say what it means for an address to be a "multiple"
of something.

--
Keith Thompson (The_Other_Keith) (e-mail address removed)  <http://www.ghoti.net/~kst>
Nokia
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

Thanks Keith...for once ( ) I will accept it is something under
the hood I will deal with if I ever need that level of programming
skill.I do have a vague general sense for it...thanks to these
replies and wikipedia!!

 

[robertwessel2]

     3) The hardware detects the misalignment and generates a trap
        as above, but software in the trap handler figures out what
        was attempted and then emulates it, using multiple memory
        accesses along with shifting and masking to get at the
        desired bytes.  This usually produces a slowdown of between
        a hundred- to a thousand-fold; that is, your 3GHz machine
        runs at an effective speed of 3-30MHz.

     4) The hardware detects the misalignment but does a hardware-
        assisted fixup, in the style of (3) but with much greater
        speed.  This usually produces a slowdown of two- to three-
        fold; your 3GHz machine runs at 1-1.5GHz.

An important case to remember exists between your (3) and (4). On
hardware like PPC or IPF, where many/most misaligned accesses can be
resolved by the hardware with a moderate speed penalty, but others,
usually involving complex cases like crossing page boundaries, are
still punted back to a software trap to be fixed up (where the
misaligned access incurs the severe performance penalty).

 

[mdh]

     "Alignment requirements" are C's recognition of, or perhaps
concession to, some realities of the ways computers are built.

Eric...thank you so much for that very extensive explanation. It is
now copied and pasted in my C "keep" files...hopefully totally
aligned!