pointer alignment

Discussion in 'C Programming' started by j0mbolar, Aug 26, 2004.

  1. j0mbolar

    j0mbolar Guest

    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?
    j0mbolar, Aug 26, 2004
    #1
    1. Advertising

  2. j0mbolar wrote:
    >
    > 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.)

    --
    +-------------------------+--------------------+-----------------------------+
    | Kenneth J. Brody | www.hvcomputer.com | |
    | kenbrody/at\spamcop.net | www.fptech.com | #include <std_disclaimer.h> |
    +-------------------------+--------------------+-----------------------------+
    Kenneth Brody, Aug 26, 2004
    #2
    1. Advertising

  3. j0mbolar

    Wojtek Lerch Guest

    "j0mbolar" <> wrote in message
    news:...
    > 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.
    Wojtek Lerch, Aug 26, 2004
    #3
  4. j0mbolar

    Thad Smith Guest

    Kenneth Brody wrote:
    >
    > j0mbolar wrote:
    > >
    > > 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 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
    Thad Smith, Aug 26, 2004
    #4
  5. j0mbolar wrote:
    > 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, Aug 27, 2004
    #5
  6. Thad Smith wrote:
    > 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).
    Douglas A. Gwyn, Aug 27, 2004
    #6
  7. j0mbolar

    Brian Inglis Guest

    On Thu, 26 Aug 2004 19:22:47 -0400 in comp.std.c, "Douglas A. Gwyn"
    <> wrote:

    >Thad Smith wrote:
    >> 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.


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

    --
    Thanks. Take care, Brian Inglis Calgary, Alberta, Canada

    (Brian[dot]Inglis{at}SystematicSW[dot]ab[dot]ca)
    fake address use address above to reply
    Brian Inglis, Aug 27, 2004
    #7
  8. Thad Smith wrote:
    >
    > Kenneth Brody wrote:
    > >
    > > j0mbolar wrote:
    > > >
    > > > 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 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.

    > > 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.


    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.

    --
    +-------------------------+--------------------+-----------------------------+
    | Kenneth J. Brody | www.hvcomputer.com | |
    | kenbrody/at\spamcop.net | www.fptech.com | #include <std_disclaimer.h> |
    +-------------------------+--------------------+-----------------------------+
    Kenneth Brody, Aug 27, 2004
    #8
  9. According to Kenneth Brody <>:
    > 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
    Thomas Pornin, Aug 29, 2004
    #9
  10. j0mbolar

    Brian Inglis Guest

    On Sun, 29 Aug 2004 08:46:15 +0000 (UTC) in comp.std.c,
    (Thomas Pornin) wrote:

    >According to Kenneth Brody <>:
    >> 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.


    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.

    --
    Thanks. Take care, Brian Inglis Calgary, Alberta, Canada

    (Brian[dot]Inglis{at}SystematicSW[dot]ab[dot]ca)
    fake address use address above to reply
    Brian Inglis, Aug 30, 2004
    #10
  11. According to Brian Inglis <>:
    > 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
    Thomas Pornin, Aug 30, 2004
    #11
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Replies:
    10
    Views:
    698
    Chris Torek
    Feb 4, 2005
  2. jimjim
    Replies:
    16
    Views:
    838
    Jordan Abel
    Mar 28, 2006
  3. Replies:
    4
    Views:
    1,253
    Fred Zwarts
    Jul 2, 2009
  4. A
    Replies:
    7
    Views:
    634
  5. , India

    pointer to an array vs pointer to pointer

    , India, Sep 20, 2011, in forum: C Programming
    Replies:
    5
    Views:
    452
    James Kuyper
    Sep 23, 2011
Loading...

Share This Page