pointer alignment

[j0mbolar]

for any pointer to T, does a pointer to T have different or can have
different alignment requirement than a pointer to pointer to T? if so,
where is the exact wording in the standard that would suggest so?

 

[Kenneth Brody]

for any pointer to T, does a pointer to T have different or can have
different alignment requirement than a pointer to pointer to T? if so,
where is the exact wording in the standard that would suggest so?

I can't quote chapter and verse, but I can tell you that on the platforms
I currently use:

A pointer to "char" has no alignment restrictions.
A pointer to a 16-bit value must be aligned on a 16-bit boundary.
(ie: the address must be even.)
Pointers are 32 bits, and a pointer-to-pointer must be aligned on
a 32-bit boundary. (ie: the address must be a multiple of 4.)

 

[Wojtek Lerch]

for any pointer to T, does a pointer to T have different or can have
different alignment requirement than a pointer to pointer to T? if so,
where is the exact wording in the standard that would suggest so?

6.2.5#26:

A pointer to void shall have the same representation and alignment
requirements as a pointer to a character type. Similarly, pointers to
qualified or unqualified versions of compatible types shall have the same
representation and alignment requirements. All pointers to structure types
shall have the same representation and alignment requirements as each other.
All pointers to union types shall have the same representation and
alignment requirements as each other. Pointers to other types need not have
the same representation or alignment requirements.

 

[Thad Smith]

I can't quote chapter and verse, but I can tell you that on the platforms
I currently use:

A pointer to "char" has no alignment restrictions.

A char has no alignment restrictions. A pointer to char may.

A pointer to a 16-bit value must be aligned on a 16-bit boundary.
(ie: the address must be even.)
Pointers are 32 bits, and a pointer-to-pointer must be aligned on
a 32-bit boundary. (ie: the address must be a multiple of 4.)

This is not required, either. In fact, PC-based computers don't need
(and at least some compilers don't have) alignment requirements for
pointers and 16-bit ints.

Thad

 

[Douglas A. Gwyn]

for any pointer to T, does a pointer to T have different or can have
different alignment requirement than a pointer to pointer to T? if so,
where is the exact wording in the standard that would suggest so?

The standard doesn't "suggest" how the implementor
should allocate storage to objects of different
types, although it does impose some constraints.
Because it doesn't say otherwise, an implementor
is free to use different sizes for different types
of object pointer.

For example, pointer to byte often employs a
multi-word representation (word_address,
offset_within_word) whereas pointer to a word-
aligned object uses a single word )word_address).
Thus, char* would be fatter than char**.

 

[Douglas A. Gwyn]

A char has no alignment restrictions. A pointer to char may.

I think he meant, the pointer value.

This is not required, either. In fact, PC-based computers don't need
(and at least some compilers don't have) alignment requirements for
pointers and 16-bit ints.

Not all computers are PCs, and even so, there can be
a performance penalty in using such unaligned access,
so a C implementation might very well adhere to such
alignment, at which point it might gain some further
benefit from being able to rely on that property.

The VAX was an early example where unaligned access
of multibyte objects was allowed, but inordinately
expensive (at least on some models).

 

[Brian Inglis]

I think he meant, the pointer value.


Not all computers are PCs, and even so, there can be
a performance penalty in using such unaligned access,
so a C implementation might very well adhere to such
alignment, at which point it might gain some further
benefit from being able to rely on that property.

Indeed, GNU C for 386&c. seems to generate a lot of alignment opcodes.

 

[Kenneth Brody]

A char has no alignment restrictions. A pointer to char may.

I guess it comes down to interpretation of the question. Yes, where
the char* is stored may have alignment restrictions, but the value of
the pointer does not.

This is not required, either. In fact, PC-based computers don't need
(and at least some compilers don't have) alignment requirements for
pointers and 16-bit ints.

True, "PC-based computers" can store anything at any valid address without
alignment restrictions. However, you do get a performance penalty for not
aligning things. The compilers I use on such systems default to using
alignment for such things, though you can turn this off.

Many other systems forbid non-aligned values and generate a fault if you
try to do so. Some of these systems will then, via software, handle the
mis-aligned access, allowing the program to run with a severe penalty hit.
Others will crash the program.

 

[Thomas Pornin]

True, "PC-based computers" can store anything at any valid address without
alignment restrictions. However, you do get a performance penalty for not
aligning things. The compilers I use on such systems default to using
alignment for such things, though you can turn this off.

Actually, in "recent" Intel (and compatible) x86 processors (I think
the 80486 is the first to have this feature), there is a flag in the
eflags register which activates alignment checks. When this flag is set,
unaligned access trigger an exception, and subsequent process death
(unless the OS traps the exception and corrects things, which is not
customary in x86-based OS).

This flag is rarely set, mostly because the standard ABIs on 32-bit x86
(ELF for the Unix world, PE for Windows) specify only 32-bit alignment
for "double" values (which is fine for a 80386, but not for a modern
Pentium, which has 64-bit alignment requirements for "double" values).

If the flag is not set, the penalty hit for misaligned access is about
one clock cycle, which is huge for the most recent processors, which
may execute many opcodes during each clock cycle. There are also cache
issues, if the misaligned access spans accross a cache line boundary.


--Thomas Pornin

 

[Brian Inglis]

True, "PC-based computers" can store anything at any valid address without
alignment restrictions. However, you do get a performance penalty for not
aligning things. The compilers I use on such systems default to using
alignment for such things, though you can turn this off.

Actually, in "recent" Intel (and compatible) x86 processors (I think
the 80486 is the first to have this feature), there is a flag in the
eflags register which activates alignment checks. When this flag is set,
unaligned access trigger an exception, and subsequent process death
(unless the OS traps the exception and corrects things, which is not
customary in x86-based OS).

This flag is rarely set, mostly because the standard ABIs on 32-bit x86
(ELF for the Unix world, PE for Windows) specify only 32-bit alignment
for "double" values (which is fine for a 80386, but not for a modern
Pentium, which has 64-bit alignment requirements for "double" values).

If the flag is not set, the penalty hit for misaligned access is about
one clock cycle, which is huge for the most recent processors, which
may execute many opcodes during each clock cycle. There are also cache
issues, if the misaligned access spans accross a cache line boundary.[/QUOTE]

This approach makes a lot of sense, as a translation unit can then be
compiled with architectural alignment internally, ABI alignment for
external interfaces, or with no alignment in packed structures, or
compiled for a slight variant of the architecture on which it runs,
suffering only a speed penalty when alignment restrictions are not
strictly obeyed, rather than failure due to an exception.

 

[Thomas Pornin]

This approach makes a lot of sense, as a translation unit can then be
compiled with architectural alignment internally, ABI alignment for
external interfaces, or with no alignment in packed structures, or
compiled for a slight variant of the architecture on which it runs,
suffering only a speed penalty when alignment restrictions are not
strictly obeyed, rather than failure due to an exception.

I prefer the Alpha way. Data access on the Alpha should be aligned;
unaligned access triggers an exception (there are also opcodes for
unaligned access, which do not fail, but which are a bit slower, with
somehow the same speed penalty then a Pentium doing an unaligned
access). Traditionaly, Unix-like OS on the Alpha trap the exception, and
perform the access by software, which implies a huge penalty (thousands
of clock cycles) but no process failure. The offending access is logged.

This way, one can use legacy code which performs unaligned access, and
the OS helps in tracking down such misbehaved programs. When I got an
Alpha as a desktop machine in 1998, I installed Linux on it, and at
that time many programs were faulty with regards to alignment (they
were designed for a 32-bit world, not a 64-bit world, and programmers
did quite evil things with their values); the most prominent villain
was the XFree server. I was quite thankful to the OS for the automatic
correction of misaligned access because XFree was quite necessary to my
daily work.


Of course, the x86 platform has a long history of allowing misaligned
access, and too much code which uses such accesses; hence, the cpu
vendors (Intel, AMD,...) have no choice but to add the necessary logic
to handle such accesses with a minimal speed penalty. From their point
of view, they would gladly do without unaligned accesses, but legacy
code is stronger.


--Thomas Pornin