padding bits 
Author Message
 padding bits

There is no mention of padding bits for integers in C89, right?
So there can't have been any compliant C89 compilers that included them.
So why was this, AFAICT unproductive, complication introduced in C99?
Did compilers provide it as an extension, and if so, why? It's been
puzzling me, and I just can't think of a reason for their existence.
Anyone have any idea?

Richard



Fri, 09 Jan 2004 22:54:39 GMT  
 padding bits

Quote:

> There is no mention of padding bits for integers in C89, right?

    No, but there is no mention of the length in bits of any of the
integer types. There is nothing precluding padding bits.

Quote:
> So there can't have been any compliant C89 compilers that included them.

    For example, imagine a platform with 9-bit chars, and the following
sizeof values:

sizeof(short)   == 2
sizeof(long)    == 4

    The standard only requires that short can hold +-32767, and that
long can hold +-2147483647. So, it is perfectly legal for the short type
to contain 2 padding bits (i.e. it's an 18-bit type, but only 16 bits
must be used), and for the long tope to contain 4 (i.e. it's a 36-bit
type, but only 32 bits must be used)

Quote:
> So why was this, AFAICT unproductive, complication introduced in C99?

    It's always been there, it's just now been more explicitly stated.

Quote:
> Did compilers provide it as an extension, and if so, why? It's been
> puzzling me, and I just can't think of a reason for their existence.

    To allow as many platforms as possible to have efficent C
implementations.

Quote:
> Anyone have any idea?

--
Clark S. Cox III

http://www.whereismyhead.com/clark/


Fri, 09 Jan 2004 23:05:21 GMT  
 padding bits



Quote:
> There is no mention of padding bits for integers in C89, right?
> So there can't have been any compliant C89 compilers that included
them.
> So why was this, AFAICT unproductive, complication introduced in
C99?
> Did compilers provide it as an extension, and if so, why? It's
been
> puzzling me, and I just can't think of a reason for their
existence.
> Anyone have any idea?

Richard,
In some recent threads parity bits have been mentioned (I did it
myself), and, abeit not mentioned IIRC, also all kinds of error
detection/correction codes come in here.
But IMHO that does not hold because:
1)It is permitted to access the object representation of any object
using unsigned char.
2)Unsigned char is defined by the standard to have CHAR_BIT bits,
all of them contributing to the value.
(I am thinking here of 6.2.6.1 and especially footnote 36). No
possibility of a parity bit (visible to the program) here.
3)So when I access the object representation of, say, an int, the
unsigned chars I get back cannot contain hardware generated/checked
redundancy information (padding _bytes_ are of course a totally
different story)
(my, possibly wrong) conclusion:
Padding bits, as they are mentioned in the standard (well, n869 in
my case) must be bits which contribute to the value of an unsigned
char if I access an object representation using unsigned char.
One example for "true" padding bits I can think of are EBCDIC
machines, where in packed decimal representation not all bitpatterns
of a stored int are valid int values and where the sign uses a whole
4-bit-nibble
(0xffffffff is not a valid EBCDIC number, but can be accessed as
four unsigned chars)
And because EBCDIC machines existed a very long time (along with
other weird internal representations) before C89 came out, maybe
this is the reason why padding bits where allowed (implicitely) in
c89 and explicitely in c99.

I don't see the padding bit thing as an unproductive complication.
Padding bits, as I understand, are necessary to permit the mapping
of non-pure-binary hardware to the pure-binary abstract machine (we
_need_ this "failsafe" unsigned char for things like core dumps).
Thus a compiler writer for a pure binary platform can simply ignore
that point, and for a non_pure-binary platform they are necessary to
make a conforming C-iplementation possible.

Kind regards
-- .
Robert Stankowic



Sat, 10 Jan 2004 00:38:39 GMT  
 padding bits

Quote:
>There is no mention of padding bits for integers in C89, right?
>So there can't have been any compliant C89 compilers that included them.

Wrong.  Consider an implementation where sizeof(int) * CHAR_BIT > 16,
but INT_MAX == 32767.  What part of C89 would this hypothetical
implementation break?

Quote:
>So why was this, AFAICT unproductive, complication introduced in C99?

To explicitly warn the reader that a conforming implementation need not
use all sizeof(integer_type) * CHAR_BIT bits.

Quote:
>Did compilers provide it as an extension, and if so, why? It's been
>puzzling me, and I just can't think of a reason for their existence.
>Anyone have any idea?

I've read of some bizarre implementation, where the integer types were
manipulated in floating point registers.  A strange property of this
implementation was that INT_MAX == UINT_MAX, because the sign bit was
not part of the mantissa.  So, on this implementation, the unsigned types
had at least one padding bit (the sign bit of the corresponding signed
types).

Dan
--
Dan Pop
CERN, IT Division

Mail:  CERN - IT, Bat. 31 1-014, CH-1211 Geneve 23, Switzerland



Sat, 10 Jan 2004 05:06:37 GMT  
 padding bits

Quote:

>There is no mention of padding bits for integers in C89, right?

I don't remember.  I'll take your word for it then...
I mean, it may not have discussed extra bit in particular,
but it did lay out what's what IMO.

Quote:
>So there can't have been any compliant C89 compilers that included them.

That doesn't necessarily follow.   If it laid out limits and
sizeof et all, then it just left the other part (padding) implicit
then.

Quote:
>So why was this, AFAICT unproductive, complication introduced in C99?
>Did compilers provide it as an extension, and if so, why? It's been
>puzzling me, and I just can't think of a reason for their existence.
>Anyone have any idea?

If you're talking about what I think you're talking about,
the things is that some CPU have longer than normal sized
types, but still put smaller things into them.
--
Greg Comeau                 Countdown to "export": December 9, 2001
Comeau C/C++ ONLINE ==>     http://www.comeaucomputing.com/tryitout
NEW: Try out libcomo, now for Windows too! Try out our C99 mode!
Special July "2fer", see http://www.comeaucomputing.com


Sat, 10 Jan 2004 09:52:57 GMT  
 padding bits

Quote:


> >There is no mention of padding bits for integers in C89, right?
> >So there can't have been any compliant C89 compilers that included them.

> Wrong.  Consider an implementation where sizeof(int) * CHAR_BIT > 16,
> but INT_MAX == 32767.  What part of C89 would this hypothetical
> implementation break?

Ok, I see this now - it wouldn't actually go against it. Damn, I don't
like this, though... it means that all my C89 programs up to now have
worked on an unportable assumption. {*filter*}.
Of course, if I'd write a 9-bit implementation, I would be loath to make
int anything but 18-bit or 36-bit. I mean, _that_ is natural for the
environment, isn't it? 16-bit isn't, it's a 9-bit type shoehorned into
8-bit expectations.

Quote:
> >Did compilers provide it as an extension, and if so, why? It's been
> >puzzling me, and I just can't think of a reason for their existence.
> >Anyone have any idea?

> I've read of some bizarre implementation, where the integer types were
> manipulated in floating point registers.  A strange property of this
> implementation was that INT_MAX == UINT_MAX, because the sign bit was
> not part of the mantissa.  So, on this implementation, the unsigned types
> had at least one padding bit (the sign bit of the corresponding signed
> types).

I'd say that this flies in the face of (my interpretation of!) the
intent of the description of unsigned types in 3.1.2.5 of your draft of
C89... then again, it probably doesn't contradict its letter, if you
want to be finicky.

Drat and double drat. I'll accept it, but I still won't like it. It's
unnatural, IYAM.

Richard



Sat, 10 Jan 2004 22:44:53 GMT  
 padding bits


Quote:

(Richard Bos) writes:

> I've read of some bizarre implementation, where the integer types were
> manipulated in floating point registers.  A strange property of this
> implementation was that INT_MAX == UINT_MAX, because the sign bit was
> not part of the mantissa.  So, on this implementation, the unsigned types
> had at least one padding bit (the sign bit of the corresponding signed
> types).

Not bizarre for DSP chips (at least the floating point ones), mind you C on
DSP chips is often weird anyway, pointers can be very odd (particularly for
memory mapped IO stuff).


Sat, 10 Jan 2004 23:24:02 GMT  
 
 [ 7 post ] 

 Relevant Pages 

1. Can pointers have padding bits?

2. Padding bits, unsigned chars.

3. integer type roundup..padding bits, wrapping

4. Dividing 42 bits / 42 bits in segments of 8 bits

5. Padding to mulitple-of-8-bytes: too much padding added

6. What precision I got with 53 bits of significand bits

7. IPAddress.Address 64-bits instead of 32-bits

8. Algorithm to convert from 24 bits to 8 bits

9. 32 bits compiler vs 16 bits library

10. flipping bits (was: Re: How to reverse bits...)

11. How to call a 16 bits DLL function from a 32 bits Exe

12. Utilisation d'une DLL 16 bits dans appli 32 bits

 

 
Powered by phpBB® Forum Software