Proposal -- new integer types [bitfields - let's free them from unions]
Author Message
Proposal -- new integer types [bitfields - let's free them from unions]

I propose that C could free bitfields from unions, [& extend them] like so:

unsigned unsigned_two_bit_number:2; /* Pun intentional */

unsigned u5:5; /* Hooray! I'm free from the union! */

unsigned ubig:400; /* That's right! I said 400. */

int signed_two_bit_number:2;

int n5:5;

int nbig:3500; /* OK, so I'm greedy. */

Now, I realize that:
1.  Integer sizes that do not fit into a hardware data type could waste
space, if there are no additional declarations to fill out the rest of the
integral type.  But if I declare a big pile of them, they could be packed.
2.  Integer sizes that are not exact fits into a hardware data type will be
less speed efficient than a hardware data type.  Packages like ECPP and
MIRACL show that integers can be easily extended, and still remain fairly
efficient.  And Tim Behrendsen's factorial function that he posted shows
that operations like multiplication can remain efficient.

Some will surely hoot and holler, but Ada can do it.  PL/1 can do it.  Why
not C?

Objections:
1.  What about array types!  We won't be able to do arrays!
Response:
These macros show how easy it is to address bits:
#define bitset( buf, bit ) ( buf[(bit) >> 3] |= ( 1 << ( (bit) & 7 )))
#define bitclr( buf, bit ) ( buf[(bit) >> 3] &= ~( 1 << ( (bit) & 7 )))
#define bittog( buf, bit ) ( buf[(bit) >> 3] ^= ( 1 << ( (bit) & 7 )))
#define bitget( buf, bit ) ((( buf[(bit) >> 3] >> ( (bit) & 7 )) & 1 ))
There are better and more efficient ways to do it than this also.

2.  What about efficiency!  unsigned u34:34 will be slow on a 32 bit chip!
Response:
Don't use them then.  But if you really need 34 bits, then you darned well
need them.

Response:
Nope, they would become native types.

[Of course, once I get my n-bit integral types, I won't be satisfied with
that.  I'll push for rational types after that, then for complex rational
types.]
Oink, Oink! said the pig.
--
I don't speak for anybody but myself, which everyone else is thankful for
( -- sig shamelessly purloined from Scott Johnson -- )

Sun, 18 Jul 1999 03:00:00 GMT
Proposal -- new integer types [bitfields - let's free them from unions]

)I propose that C could free bitfields from unions, [& extend them] like so:
)
)       unsigned unsigned_two_bit_number:2; /* Pun intentional */
)
)       unsigned u5:5; /* Hooray! I'm free from the union! */
)
)       unsigned ubig:400; /* That's right! I said 400. */
)
)
)       int signed_two_bit_number:2;
)
)       int n5:5;
)
)       int nbig:3500; /* OK, so I'm greedy. */
)

IMHO, this is not the extension bit fields need. What they would really
be useful for is defining hardware registers with bit fields in them.
But they are not really useful for that, because of the "implementation
dependencies" placed on them. One needs to be able to specify exactly
where in the word they are placed, and exactly what the size of the word
is that contains them. Until the syntax is extended to include this
level of control, they are basically useless for anything else.

Mike
--
----
char *p="char *p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);}
This message made from 100% recycled bits.
I don't speak for DSC.         <- They make me say that.

Tue, 20 Jul 1999 03:00:00 GMT
Proposal -- new integer types [bitfields - let's free them from unions]

Quote:

> )I propose that C could free bitfields from unions, [& extend them] like
so:
> )
> )  unsigned unsigned_two_bit_number:2; /* Pun intentional */
> )
> )  unsigned u5:5; /* Hooray! I'm free from the union! */
> )
> )  unsigned ubig:400; /* That's right! I said 400. */
> )
> )
> )  int signed_two_bit_number:2;
> )
> )  int n5:5;
> )
> )  int nbig:3500; /* OK, so I'm greedy. */
> )

> IMHO, this is not the extension bit fields need. What they would really
> be useful for is defining hardware registers with bit fields in them.
> But they are not really useful for that, because of the "implementation
> dependencies" placed on them. One needs to be able to specify exactly
> where in the word they are placed, and exactly what the size of the word
> is that contains them. Until the syntax is extended to include this
> level of control, they are basically useless for anything else.

This kind of thing should always be done in assembly language.  If you want
your bits to live in some certain part of a register, then this will
obviously change from CPU to CPU, so there will be little use trying to
define it in C.  On the other hand, suppose that you want a numeric type
that goes from [0 to 1] (period).  Then use:
unsigned onebit:1;
On the other hand, what if you need a 64 bit integer, and your CPU does not
have one?  Then use:
int i64:64;
The compiler manufacturers are free to make these operations as efficient
as possible for a given CPU.  I often want data types that are not provided
by the language.  It would be nice if there were a consistent way to define
them.  Arbitrary sized integers is something we see in C++ (and even in C,
but as library calls).  Since everyone does it a different way, there is no
standard way to code for this.  If we had 'bit definable' int types, that
would:
1.  End the call for an equivalent to fortran's INTEGER*1, INTEGER*2,
INTEGER*4 data types
2.  Eliminate the foolish and annoying need for "long long".
3.  Make code truly portable when it has to be.

These data types are useful.  Why do you think that Ada bothers to define
arbitrary precision?  Or why are all those C++ classes that do it found
scattered about the net?  Because it solves a common set of problems.
The one [monstrous] problem I see is that sizeof should return
[(nbits/CHAR_BIT)] for an nbit type type!  I doubt if the C language
lawyers would be happy about sizeof returning a rational number.

Fri, 23 Jul 1999 03:00:00 GMT

 Page 1 of 1 [ 3 post ]

Relevant Pages