Padding Bits

Discussion in 'C Programming' started by John Messenger, Feb 10, 2008.

  1. I notice that the C standard allows padding bits in both unsigned and
    signed integer types. Does anyone know of any real-world examples of
    compilers that use padding bits?

    --
    John
    John Messenger, Feb 10, 2008
    #1
    1. Advertising

  2. John Messenger

    Ike Naar Guest

    John Messenger <> wrote:
    >I notice that the C standard allows padding bits in both unsigned and
    >signed integer types. Does anyone know of any real-world examples of
    >compilers that use padding bits?


    The Burroughs B7700 has 48-bit words.
    Integer numbers have a sign-and-magnitude representation, using 1 bit
    for the sign and 39 bits for the magnitude; the remaining 8 bits are left
    unused (floatingpoint numbers use these bits for the exponent).

    See also http://home.hetnet.nl/mr_1/81/jhm.bonten/computers/bitsandbytes/wordsizes/unisys.htm#gene

    Ike
    Ike Naar, Feb 10, 2008
    #2
    1. Advertising

  3. On Sun, 10 Feb 2008 12:31:55 +0000, Ike Naar wrote:

    > John Messenger <> wrote:
    >>I notice that the C standard allows padding bits in both unsigned and
    >>signed integer types. Does anyone know of any real-world examples of
    >>compilers that use padding bits?

    >
    > The Burroughs B7700 has 48-bit words. Integer numbers have a
    > sign-and-magnitude representation, using 1 bit for the sign and 39 bits
    > for the magnitude; the remaining 8 bits are left unused (floatingpoint
    > numbers use these bits for the exponent).
    >
    > See also
    > http://home.hetnet.nl/mr_1/81/jhm.bonten/computers/bitsandbytes/

    wordsizes/unisys.htm#gene
    >
    > Ike


    The Burroughs B7700 might have 48-bit words with padding bits, but it
    appears to not have a C compiler, let alone a Standard C compiler. Ernie
    took these pictures (one of the Burroughs B7700) in 1981, which was about
    a decade before the first C Standard came out.

    http://www.eecis.udel.edu/~mader/delta/erniepics.html

    Based on the lack of responses to my question, I have to conclude that
    there are no real-world examples of C compilers that use padding bits, so
    we never have to deal with padding bits in the real world.

    --
    John
    John Messenger, Feb 11, 2008
    #3
  4. John Messenger said:

    <snip>

    > Based on the lack of responses to my question, I have to conclude that
    > there are no real-world examples of C compilers that use padding bits, so
    > we never have to deal with padding bits in the real world.


    Yeah. Everything's already been invented, too, so there's no need to worry
    about future implementations or architectures.

    And if you'd asked instead, say, whether anyone had used any non-ASCII
    character sets, and it just happened that nobody who had done so bothered
    to respond to your article, would you have concluded that non-ASCII
    character sets do not now and will never exist?

    I have an idea for you, which will be a great time-saver. Up until now,
    presumably you've written a number of programs over the course of your
    career. All of those programs obviously meet a real world requirement,
    otherwise you wouldn't have written them. But how about any other programs
    you might consider writing? Forget it - if they had any real world
    utility, you would already have written them.

    Everything has been invented, all the world's a 32-bit PC running Windows,
    and the world has an infinite supply of oil.

    Happy days.

    --
    Richard Heathfield <http://www.cpax.org.uk>
    Email: -http://www. +rjh@
    Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
    "Usenet is a strange place" - dmr 29 July 1999
    Richard Heathfield, Feb 11, 2008
    #4
  5. John Messenger <> writes:
    [...]
    > The Burroughs B7700 might have 48-bit words with padding bits, but it
    > appears to not have a C compiler, let alone a Standard C compiler. Ernie
    > took these pictures (one of the Burroughs B7700) in 1981, which was about
    > a decade before the first C Standard came out.
    >
    > http://www.eecis.udel.edu/~mader/delta/erniepics.html
    >
    > Based on the lack of responses to my question, I have to conclude that
    > there are no real-world examples of C compilers that use padding bits, so
    > we never have to deal with padding bits in the real world.


    That's a bad assumption. The lack of a definitive response in less
    that 24 hours (on a weekend, yet), really proves nothing.

    I believe that Cray vector machines such as the T90 have (had?)
    padding bits for some integer types. I don't recall the exact
    details, but such machines certainly had reasonably conforming C90
    compilers (but not C99 compilers).

    There may well be other examples. Perhaps more to the point, there
    could easily be other examples in the future.

    --
    Keith Thompson (The_Other_Keith) <>
    Nokia
    "We must do something. This is something. Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
    Keith Thompson, Feb 11, 2008
    #5
  6. On Mon, 11 Feb 2008 07:38:58 +0000, Richard Heathfield wrote:

    > John Messenger said:
    >
    > <snip>
    >
    >> Based on the lack of responses to my question, I have to conclude that
    >> there are no real-world examples of C compilers that use padding bits,
    >> so we never have to deal with padding bits in the real world.

    >
    > Yeah. Everything's already been invented, too, so there's no need to
    > worry about future implementations or architectures.


    I should have qualified my response as saying that we *currently* do not
    have to deal with padding bits in the real world. Not with gcc under
    Linux, or MS VC++ in Windows, or with all of the embedded C compilers we
    use (which mainly run under Windows).

    Future implementations or architectures may well decide to include
    padding bits in integer types, and if so, we'll have to deal with that
    decision. In all likelihood, though, the next breakthrough in computer
    architecture will be 128-bit integers, and they won't use any padding
    bits.

    The motivation for asking my question comes from having to deal with C
    programmers who, unlike you and me and the other experts in this
    newsgroup, don't know the least thing about padding bits in integer
    types, and therefore don't know about how to deal with the ramifications
    of implementing code that might be compromised by a compiler that defines
    padding bits. If there are no compilers in the real world that use
    padding bits in integer types, then my job of managing these people
    becomes a lot easier.

    > And if you'd asked instead, say, whether anyone had used any non-ASCII
    > character sets, and it just happened that nobody who had done so
    > bothered to respond to your article, would you have concluded that
    > non-ASCII character sets do not now and will never exist?


    Yes.

    ASCII is the de facto standard for C code in general and source code
    distribution in general. Any time one distributes source code via an
    electronic medium (whether it is on a CD, or in a compressed archive such
    as GZIP or ZIP or BZ or whatever, or in a simple uncompressed format,
    etc.), they have committed to using a specific character encoding,
    whether they are aware of it or like it or not.

    You, and your companions, in fact, distribute the source code for the
    examples in the book "C Unleashed" in ASCII encoding, right? By doing so,
    you have conformed to the de facto use of ASCII character encoding, and
    at the same time gave all of those no hope in using your source code if
    they use a compiler that uses any character encoding other than ASCII.
    Did you and the others who wrote "C Unleashed" include any type of
    disclaimer similar to the following?

    "The source code on the companion CD is stored in the ASCII encoding
    format. If you use any C compiler that does not expect the ASCII encoding
    format, this code will most likely not compile. Don't blame this on the C
    Standard--blame it on us".

    The only sure way to "distribute" portable C source code is via such
    mediums as printed books or printed graphics (e.g., what you see on your
    monitor when viewing web pages on The Internet, or when viewing posts on
    Usenet, etc.). Although guaranteed to be portable, users would be overly
    burdened by having to convert there graphics to source files (encoded in
    their compiler's required format--ASCII, EBCDIC, etc.) using some
    arguably amazing character recognition program.

    Imagine if, for the sake of true portability, all currently distributed
    open source distributions (mainly GZ or BZ2 file) were instead
    distributed as character glyphs on a web page--and you were responsible
    for converting these graphics to files in your compiler's expected
    character encoding.

    [snip]

    > Everything has been invented, all the world's a 32-bit PC running
    > Windows, and the world has an infinite supply of oil.


    And all the world's 32-bit or 64-bit Linux. And food comes from the
    supermarket. And water comes from the faucet.

    Whether we like it or not, there are people in the real world who think
    this way, and we have to deal with them. And if these people don't have
    to worry about padding bits in integer types, then it makes our job a lot
    easier when managing them. And, thankfully, these people will never work
    on C code targeted for the Burroughs B7700.

    --
    John
    John Messenger, Feb 11, 2008
    #6
  7. John Messenger

    Army1987 Guest

    John Messenger wrote:

    > The only sure way to "distribute" portable C source code is via such
    > mediums as printed books or printed graphics (e.g., what you see on your
    > monitor when viewing web pages on The Internet, or when viewing posts on
    > Usenet, etc.). Although guaranteed to be portable, users would be overly
    > burdened by having to convert there graphics to source files (encoded in
    > their compiler's required format--ASCII, EBCDIC, etc.) using some
    > arguably amazing character recognition program.


    As long as they only use characters from the basic character set, using
    ASCII is just a choice, and there are programs automatically converting
    ASCII to EBCDIC. OTOH, the standard doesn't require characters to have
    particular glyphs -- that's why trigraphs and <iso646.h> exist, the glyphs
    for { or | in some character sets make programs unreadable.

    As for which implementations have padding bits, the C99 rationale says:
    6.2.6.2 Integer types
    Padding bits are user-accessible in an unsigned integer type. For example, suppose a machine
    uses a pair of 16-bit shorts (each with its own sign bit) to make up a 32-bit int and the sign
    bit of the lower short is ignored when used in this 32-bit int. Then, as a 32-bit signed
    int, there is a padding bit (in the middle of the 32 bits) that is ignored in determining the value
    20 of the 32-bit signed int. But, if this 32-bit item is treated as a 32-bit unsigned int, then
    that padding bit is visible to the user’s program. The C committee was told that there is a
    machine that works this way, and that is one reason that padding bits were added to C99.
    Footnotes 44 and 45 mention that parity bits might be padding bits. The committee does not
    know of any machines with user-accessible parity bits within an integer. Therefore, the
    25 committee is not aware of any machines that treat parity bits as padding bits.

    Since then, it was required that all-bits-zero be a valid representation
    of 0 in any integral type, as many programs expect this (e.g. using
    calloc) and there was no known implementation where it wasn't. This rules
    out odd parity bits, or at least requires all-bits-zero as an exception.

    --
    Army1987 (Replace "NOSPAM" with "email")
    Army1987, Feb 11, 2008
    #7
  8. John Messenger said:

    <snip>

    > If there are no compilers in the real world that use
    > padding bits in integer types, then my job of managing these people
    > becomes a lot easier.


    Indeed. But of course it has not been shown that there are no such
    compilers. All that has been shown is that only one of the small handful
    of people who read your article over this weekend has come across a
    hardware platform that uses padding bits.

    I'm put in mind of a (blessedly hypothetical) physicist, being asked 35
    years ago whether the irrational number 4.66920160910299067... had any
    practical significance in the real world, and answering with a resounding
    "NO, sir! None whatsoever."

    >> And if you'd asked instead, say, whether anyone had used any non-ASCII
    >> character sets, and it just happened that nobody who had done so
    >> bothered to respond to your article, would you have concluded that
    >> non-ASCII character sets do not now and will never exist?

    >
    > Yes.


    Then just hope and pray that your code never has to work on a mainframe.

    > ASCII is the de facto standard for C code in general and source code
    > distribution in general.


    More or less true (although exceptions exist), but nevertheless beside the
    point.

    > Any time one distributes source code via an
    > electronic medium (whether it is on a CD, or in a compressed archive such
    > as GZIP or ZIP or BZ or whatever, or in a simple uncompressed format,
    > etc.), they have committed to using a specific character encoding,
    > whether they are aware of it or like it or not.


    It is fairly trivial, having taken delivery of such C code, to convert it
    to another encoding. What is not so trivial is to identify all the code
    that relies on the runtime data being encoded in ASCII. if(x == 9), for
    example. Or if(x < 32) is quite common, too. As is ch - 48.

    > You, and your companions, in fact, distribute the source code for the
    > examples in the book "C Unleashed" in ASCII encoding, right?


    You have, indeed, completely and utterly missed the point. The code I wrote
    for that book works just fine on mainframes using non-ASCII encodings. All
    you have to do is tell the 3270 emulator to convert ASCII to EBCDIC during
    the file transfer.

    <snip>

    > Did you and the others who wrote "C Unleashed" include any type of
    > disclaimer similar to the following?
    >
    > "The source code on the companion CD is stored in the ASCII encoding
    > format. If you use any C compiler that does not expect the ASCII encoding
    > format, this code will most likely not compile. Don't blame this on the C
    > Standard--blame it on us".


    No, we didn't include any such disclaimer. The book is intended for use by
    programmers with some existing professional-level experience of C, and any
    such people who use non-ASCII encodings will already know how to convert
    ASCII to their own encoding. But I will say that, if any of the code from
    the book were found to rely on a host environment that uses ASCII (or
    indeed any specific encoding) at compile time or run time, we would
    consider that to be a bug.

    In the same way, I consider code that relies on the absence of padding bits
    to be less good than code that does not have that reliance. Such
    assumptions have a habit of becoming invalid at the worst possible moment.

    <snip>

    --
    Richard Heathfield <http://www.cpax.org.uk>
    Email: -http://www. +rjh@
    Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
    "Usenet is a strange place" - dmr 29 July 1999
    Richard Heathfield, Feb 11, 2008
    #8
  9. John Messenger

    Randy Howard Guest

    On Mon, 11 Feb 2008 01:23:31 -0600, John Messenger wrote
    (in article <TJSrj.7603$>):

    > http://www.eecis.udel.edu/~mader/delta/erniepics.html


    Interesting link. Reminds me of similar setups elsewhere. Wish I had
    realized how useful having pictures of such would be today. I also
    wish the stacks of old reference material I threw out, sold or gave
    away was still in my possession. :)

    > Based on the lack of responses to my question, I have to conclude that
    > there are no real-world examples of C compilers that use padding bits, so
    > we never have to deal with padding bits in the real world.


    I wouldn't be so sure about that. I can't recall completely, and the
    docs are in a box in the attic somewhere atm, but I seem to recall
    Itanium having support for 120-bit objects for something or another,
    which have implied some oddities for a compiler that used them. I
    can't dredge up anything concrete though. A bunch of bookmarks I had
    for documents at developer.intel.com are dead now. Maybe someone else
    can confirm/deny.

    Modern GPUs might be another area where such might crop up.






    --
    Randy Howard (2reply remove FOOBAR)
    "The power of accurate observation is called cynicism by those
    who have not got it." - George Bernard Shaw
    Randy Howard, Feb 11, 2008
    #9
  10. John Messenger

    Ike Naar Guest

    John Messenger <> wrote:
    >The Burroughs B7700 might have 48-bit words with padding bits, but it
    >appears to not have a C compiler, let alone a Standard C compiler. Ernie
    >took these pictures (one of the Burroughs B7700) in 1981, which was about
    >a decade before the first C Standard came out.


    A compiler could have been written after those pictures were taken.

    >Based on the lack of responses to my question, I have to conclude that
    >there are no real-world examples of C compilers that use padding bits, so
    >we never have to deal with padding bits in the real world.


    Don't confuse the "real world" with the small corner you're living in.

    Regards,
    Ike
    Ike Naar, Feb 11, 2008
    #10
    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. copx

    padding bits...

    copx, Mar 1, 2005, in forum: C Programming
    Replies:
    8
    Views:
    400
    Gordon Burditt
    Mar 2, 2005
  2. Hallvard B Furuseth

    Padding bits and struct assignment

    Hallvard B Furuseth, Dec 27, 2006, in forum: C Programming
    Replies:
    5
    Views:
    628
    Eric Sosman
    Dec 27, 2006
  3. john

    Padding bits

    john, Nov 2, 2007, in forum: C++
    Replies:
    7
    Views:
    354
    EventHelix.com
    Nov 3, 2007
  4. Ioannis Vranos
    Replies:
    11
    Views:
    744
    Ioannis Vranos
    Mar 28, 2008
  5. Ioannis Vranos

    Padding bits and char, unsigned char, signed char

    Ioannis Vranos, Mar 28, 2008, in forum: C Programming
    Replies:
    6
    Views:
    600
    Ben Bacarisse
    Mar 29, 2008
Loading...

Share This Page