Array of bitfields

[Mehta Shailendrakumar]

Hi,

I would like to know why array of bitfields is not possible.
Is there any relation with processor architecture for this?
Thank you for your time.

Regards,
Shailendra

 

[junky_fellow]

Hi,

I would like to know why array of bitfields is not possible.
Is there any relation with processor architecture for this?
Thank you for your time.

Regards,
Shailendra

If the bit is an addressable unit on your implementation,
you may have an array of bitfields.

 

[SM Ryan]

# Hi,
#
# I would like to know why array of bitfields is not possible.
# Is there any relation with processor architecture for this?
# Thank you for your time.

Because C concentrates on things that are easy to implement in the hardware
and generally leaves harder stuff to libraries rather than implemented
in the syntax. Not many CPUs provide extracting or storing or moving
bit vectors of arbitrary length or orientation. You can do this in your
own code. For example if your CPU allows unaligned access to integers,
32 bit integers and 8 bit bytes,

int getSignedBits(char *base,int bitoffset,int bitlength) {
assert(bitlength<=32);
int *intaddress = base+(bitoffset>>3); // First byte with value.
int value = *intaddress; // Get all of the bits.
value <<= offset & 7; // field sign bit -> int sign.
value >>= 32-bitlength; // field lsb -> int lsb.
return value;
}

 

[Eric Sosman]

If the bit is an addressable unit on your implementation,
you may have an array of bitfields.

Not in C, you can't.

The problem is that C's array operations are defined
in terms of pointers to the array elements -- a is
defined to be *(a+i), for example. However, a C pointer
cannot point to a bit-field; the "smallest" object a C
pointer can point to is a char. Since it's not possible
to create a pointer to a bit-field, it's not possible to
carry out operations like array indexing that are defined
in terms of pointers.

The underlying hardware may be capable of addressing
individual bits, but C has no way to use that capability.
(The underlying hardware usually has a lot of things C
cannot use: circular shifts, a "carry" flag, memory
protection, vector instructions, hyperthreading, and
so on. C's vocabulary is not rich enough to talk about
such things, so C programs cannot use them.)

 

[Lawrence Kirby]

Hi,

I would like to know why array of bitfields is not possible.

Because the designers of C decided not to add support for these to the
language. We can try to guess why that is the case, but that is the
fundamental reason.

Is there any relation with processor architecture for this?

Nor really. They would be easier/more efficient to implement on some
architectures than others but they are doable on any architecture that
supports C. That's easy to show because you can write portable C code that
implements them using bit operations on integer types. That is one
possible reason why the designers of C decided that the language didn't
need to support them directly.

Lawrence

 

[Jean-Claude Arbaut]

Le 17/06/2005 19:09, dans (e-mail address removed),

Because the designers of C decided not to add support for these to the
language. We can try to guess why that is the case, but that is the
fundamental reason.

That reminds me of MATLAB's "why" command

Nor really. They would be easier/more efficient to implement on some
architectures than others but they are doable on any architecture that
supports C. That's easy to show because you can write portable C code that
implements them using bit operations on integer types. That is one
possible reason why the designers of C decided that the language didn't
need to support them directly.

I'm glad they decided that "goto" and "if" were not enough for
flow control F66 designers were not as bright :-D

 

[Walter Roberson]

I'm glad they decided that "goto" and "if" were not enough for
flow control F66 designers were not as bright :-D

Even Fortran I had a DO loop.

[I posted the reference a couple of days ago.]

 

[Jean-Claude Arbaut]

Le 17/06/2005 21:49, dans [email protected], « Walter

Even Fortran I had a DO loop.

But no WHILE, and if I remember well, it had a strange IF.
I exaggerated, the Fortran language was and still is
a great language. And in 1954, it was an extraordinary
breakthrough. It's just bad luck the language has
evolved to slowly.

 

[Martijn]

I would like to know why array of bitfields is not possible.

Is there any relation with processor architecture for this?
Thank you for your time.

Well, on with the shameless plug: if you check my website (the libraries
section) you will find an implementation of a bitmatrix (2 x 2 array of
bits) - it might help you get what you want.

Good luck,

 

[yatindran]

I agree with you.But,if you have programmed in the Keil 8051 C
compiler, you have a datatype called "bit", which can store a value of
0 or 1.It is used to store certain bit-addressable pin values and is
very commonplace in 8051 C.
for Ex,
bit PIN1 = 0;
if(PIN1)
{
.....
}
else
{
....
}
etc.

 

[Tim Rentsch]

I would like to know why array of bitfields is not possible.
Is there any relation with processor architecture for this?
Thank you for your time.

Bitfields aren't addressable; you can't take the address of a
bitfield with the '&' operator, for example.

Because bitfields aren't addressable, they can't be used for
arrays, because of how arrays and pointers work. No addresses,
no arrays.

An array of bitfield values may be manufactured using a struct,
thusly:

struct { unsigned value:4; } bitfield_array[10];

i = bitfield_array[0].value;
bitfield_array[1].value = j;

Of course, the values in the array won't be tightly packed.
There will be unused space between the values, unless the number
of bits and the padding requirements for the struct that the
values are in happen by lucky coincidence to leave no wasted
space. But if what you want is an array of bitfield values
and some inter-field padding doesn't matter, this approach
could fill the bill.

 

[pete]

I agree with you.But,if you have programmed in the Keil 8051 C
compiler, you have a datatype called "bit", which can store a value of
0 or 1.It is used to store certain bit-addressable pin values and is
very commonplace in 8051 C.
for Ex,
bit PIN1 = 0;

That looks like C to you?
If that's 8051 C, then 8051 C, isn't C.

 

[SM Ryan]

# (e-mail address removed) wrote:
# >
# > I agree with you.But,if you have programmed in the Keil 8051 C
# > compiler, you have a datatype called "bit", which can store a value of
# > 0 or 1.It is used to store certain bit-addressable pin values and is
# > very commonplace in 8051 C.
# > for Ex,
# > bit PIN1 = 0;
#
# That looks like C to you?
# If that's 8051 C, then 8051 C, isn't C.

ANSI doesn't have a trademark on the third letter of the alphabet.
There are many varieties of C other than ANSI's.

 

[Jean-Claude Arbaut]

Le 18/06/2005 15:53, dans (e-mail address removed), « SM Ryan »

# (e-mail address removed) wrote:
# >
# > I agree with you.But,if you have programmed in the Keil 8051 C
# > compiler, you have a datatype called "bit", which can store a value of
# > 0 or 1.It is used to store certain bit-addressable pin values and is
# > very commonplace in 8051 C.
# > for Ex,
# > bit PIN1 = 0;
#
# That looks like C to you?
# If that's 8051 C, then 8051 C, isn't C.

ANSI doesn't have a trademark on the third letter of the alphabet.
There are many varieties of C other than ANSI's.

Standards are written to avoid spreading of incompatible compilers
(and probably many other good reasons).
You can invent a BASIC-like language and call that C if this pleases you,
but don't come on c.l.c, cause this IS related to ISO C.
If you really don't understand what a standard benefit is, just have a look
at Fortran history before standardization. Look also at BASIC, not
standardized as far as I know, and a least I don't know any two compilers
for the same BASIC variant.

 

[SM Ryan]

# but don't come on c.l.c, cause this IS related to ISO C.

If you wanted a moderated newsgroup, then make a moderated newsgroup.
Until then, you don't get to decide what other people post.

# If you really don't understand what a standard benefit is, just have a look

Irrelevant. Neither ANSI nor ISO owns a trademark on 'C'.

 

[Jean-Claude Arbaut]

Le 18/06/2005 17:03, dans (e-mail address removed), « SM Ryan »

# but don't come on c.l.c, cause this IS related to ISO C.

If you wanted a moderated newsgroup, then make a moderated newsgroup.
Until then, you don't get to decide what other people post.

That's right, but it doesn't prevent from flaming. I was several times for
the same reason. Now I know what c.l.c is for, I am careful.

If you wanted a non-ISO C newsgroup, then make a comp.lang.c.blabla.
Until then, you don't get to decide what is valid here. BTW I considered
this option, but c.l.c and comp.programming are sufficient for my usage.

 

[Martin Ambuhl]

# but don't come on c.l.c, cause this IS related to ISO C.

If you wanted a moderated newsgroup, then make a moderated newsgroup.
Until then, you don't get to decide what other people post.

# If you really don't understand what a standard benefit is, just have a look

Irrelevant. Neither ANSI nor ISO owns a trademark on 'C'.

Your post before this merely showed ignorance; this one exposes you as a
troll.
*PLONK*

 

[CBFalconer]

Your post before this merely showed ignorance; this one exposes
you as a troll.
*PLONK*

He has been long gone from here, primarily for inability to mark
quotes correctly. Another indication of a non-intelligent troll.

 

[Walter Roberson]

He has been long gone from here, primarily for inability to mark
quotes correctly.

There is no "correct" way to mark quotes: only -conventions-
that are followed to various degrees. If you feel that there
is a "correct" way to mark Usenet quotes, then you are welcome to
cite an RFC, IEEE standard, ISO standard, page in K&R (any
edition), any book by K., R., or P., government regulation
in any country, or statute in -any- jurisdiction which has
the authority to create criminal offenses.

And No, the behaviour of your newsreader or of Google Groups
in automatic colorization or other forms of highlighting
are -not- evidence of "correct" behaviour.


Keith got it right months ago: there is no "correct" way of
marking quotes, just ways that irritate different sets of people.

-Every- quoting convention offends -someone-; it is up to each
individual to choose which set of people they are willing to offend.

 

[Martijn]

He has been long gone from here, primarily for inability to mark

There is no "correct" way to mark quotes: only -conventions-
that are followed to various degrees.

[snipped]

-Every- quoting convention offends -someone-; it is up to each
individual to choose which set of people they are willing to offend.

Just like "incorrect" separators for the signatures. Then again, these
conventions are there to make the life of a poster more convenient, and I
comply only for that reason. And honestly, a _lot_ of software depends on
those conventions, not only for color highlighting, but also for readjusting
message width and the sorts.

"Can't we all just get along??"