Padding Bits

[John Messenger]

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?

 

[Ike Naar]

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

 

[John Messenger]

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.

 

[Richard Heathfield]

John Messenger said:

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.

 

[Keith Thompson]

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.

 

[John Messenger]

John Messenger said:



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.

 

[Army1987]

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.

 

[Richard Heathfield]

John Messenger said:

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

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.

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>

 

[Randy Howard]

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.

 

[Ike Naar]

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