Re: Inconsistent results between char/short/int

Discussion in 'C Programming' started by Eric Sosman, Sep 24, 2011.

  1. Eric Sosman

    Eric Sosman Guest

    On 9/23/2011 9:46 AM, Guillaume Dargaud wrote:
    > Hello all,
    > I know it's frowned upon to post system-specific code here, but I'd like to
    > know if the error is in my C code (wrong pointer manipulation), in my
    > handling of Linux virtual mem or in weird CPU mem alignments (it's a PPC
    > processor).
    >[...]
    > # ./Peek -w 0x81600001 0x10
    > 81600001~48006001: 00000000 00000000 00000000 00000000 ................
    > 81600011~48006011: 00000000 00000000 00000000 00000000 ................
    > 81600021~48006021: 00000000 00000000 00000000 00000000 ................
    > 81600031~48006031: 00000000 00000000 00000000 00000000 ................


    In addition to the comments others have offered, it's quite
    possible that your processor is unhappy trying to fetch four-byte
    integers from odd addresses. Different processors will behave
    differently in the face of improper alignment; among the behaviors
    I've actually seen are

    - The processor traps, and the O/S terminates the program
    (often with "SIGBUS" or something like it).

    - The processor traps, and low-level code simulates the
    invalid operation in software, loading bytes one by one
    and assembling the result for you. The program works but
    takes a thousand or so times as long as if the access had
    been properly aligned.

    - The processor handles the load-and-assemble part without a
    trap and without software intervention. The program works
    but takes two to eight times as long as normal.

    - The processor completely ignores the offending low-order
    address bits, so when you fetch an int from 0x81600001 you
    get the four bytes 0x81600000-0x81600003 instead of the
    intended 0x81600001-0x81600004. Peculiar results ensue.

    This list is not exhaustive of all possible outcomes; it's
    just the outcomes I personally have observed. And it's meant as
    a warning that your program is on uncertain ground ...

    --
    Eric Sosman
    d
     
    Eric Sosman, Sep 24, 2011
    #1
    1. Advertising

  2. Eric Sosman

    Nobody Guest

    On Fri, 23 Sep 2011 20:21:31 -0400, Eric Sosman wrote:

    > - The processor completely ignores the offending low-order
    > address bits, so when you fetch an int from 0x81600001 you
    > get the four bytes 0x81600000-0x81600003 instead of the
    > intended 0x81600001-0x81600004. Peculiar results ensue.


    The historical ARM behaviour is similar, but with the result rotated such
    that the byte at the specified address is the least significant byte of
    the result.

    IOW, reads use the top 30 bits to determine the address, and the
    bottom 2 bits to determine the rotation. Byte reads mask the resulting
    word with 0xFF, word reads don't.
     
    Nobody, Sep 24, 2011
    #2
    1. Advertising

  3. Eric Sosman

    Jorgen Grahn Guest

    On Sat, 2011-09-24, Eric Sosman wrote:
    > On 9/23/2011 9:46 AM, Guillaume Dargaud wrote:
    >> Hello all,
    >> I know it's frowned upon to post system-specific code here, but I'd like to
    >> know if the error is in my C code (wrong pointer manipulation), in my
    >> handling of Linux virtual mem or in weird CPU mem alignments (it's a PPC
    >> processor).


    Speaking as a C programmer, whatever PPC may do isn't weird. If your
    code breaks on PPC, it's because it's broken from a language standpoint.

    >> # ./Peek -w 0x81600001 0x10
    >> 81600001~48006001: 00000000 00000000 00000000 00000000 ................
    >> 81600011~48006011: 00000000 00000000 00000000 00000000 ................
    >> 81600021~48006021: 00000000 00000000 00000000 00000000 ................
    >> 81600031~48006031: 00000000 00000000 00000000 00000000 ................

    >
    > In addition to the comments others have offered, it's quite
    > possible that your processor is unhappy trying to fetch four-byte
    > integers from odd addresses.


    > Different processors will behave
    > differently in the face of improper alignment; among the behaviors
    > I've actually seen are

    ....

    > - The processor handles the load-and-assemble part without a
    > trap and without software intervention. The program works
    > but takes two to eight times as long as normal.


    I'm pretty sure PPC belongs to the "minor slowdown" category. I write
    PPC code for a living, and treat casts which may cause misalignment as
    minor bugs, worth fixing if I'm rewriting that part anyway for other
    reasons.

    /Jorgen

    --
    // Jorgen Grahn <grahn@ Oo o. . .
    \X/ snipabacken.se> O o .
     
    Jorgen Grahn, Sep 29, 2011
    #3
    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. Schnoffos
    Replies:
    2
    Views:
    1,251
    Martien Verbruggen
    Jun 27, 2003
  2. trey

    newbie: char* int and char *int

    trey, Sep 10, 2003, in forum: C Programming
    Replies:
    7
    Views:
    425
    Irrwahn Grausewitz
    Sep 10, 2003
  3. Hal Styli
    Replies:
    14
    Views:
    1,709
    Old Wolf
    Jan 20, 2004
  4. gert
    Replies:
    20
    Views:
    1,220
  5. gershar
    Replies:
    5
    Views:
    238
    gershar
    Oct 26, 2010
Loading...

Share This Page