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?

--
John

[Ike Naar]

Re: Padding Bits

John Messenger <johnm1234@newc omp.netwrote:

>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.bo...nisys.htm#gene

Ike

[John Messenger]

Re: Padding Bits

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

John Messenger <johnm1234@newc omp.netwrote:

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

[Richard Heathfield]

Re: Padding Bits

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

[John Messenger]

Re: Padding Bits

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

[Army1987]

Re: Padding Bits

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.hexis t, 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")

[Ike Naar]

Re: Padding Bits

John Messenger <johnm1234@newc omp.netwrote:

>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