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]

Mehta Shailendrakumar wrote:

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]

"Mehta Shailendrakumar" <sh*******************@de.bosch.com> wrote:
# 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;
}

--
SM Ryan http://www.rawbw.com/~wyrmwif/
I think that's kinda of personal; I don't think I should answer that.

[Eric Sosman]

ju**********@yahoo.co.in wrote:

Mehta Shailendrakumar wrote:

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.

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[i] 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.)

--
Eric Sosman
es*****@acm-dot-org.invalid

[Lawrence Kirby]

On Fri, 17 Jun 2005 13:39:21 +0200, Mehta Shailendrakumar wrote:

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 pa****************************@netactive.co.uk,
«*Lawrence Kirby*» <lk****@netactive.co.uk> a écrit*:

On Fri, 17 Jun 2005 13:39:21 +0200, Mehta Shailendrakumar wrote:

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.

That reminds me of MATLAB's "why" command :-)

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.

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

[Walter Roberson]

In article <BE******************************@laposte.net>,
Jean-Claude Arbaut <je****************@laposte.net> wrote:

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.]
--
Entropy is the logarithm of probability -- Boltzmann

[Jean-Claude Arbaut]

Le 17/06/2005 21:49, dans d8*********@canopus.cc.umanitoba.ca, «*Walter
Roberson*» <ro******@ibd.nrc-cnrc.gc.ca> a écrit*:

In article <BE******************************@laposte.net>,
Jean-Claude Arbaut <je****************@laposte.net> wrote:

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.

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,

--
Martijn
http://www.sereneconcepts.nl

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

Eric Sosman wrote:

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[i] 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.)

--
Eric Sosman
es*****@acm-dot-org.invalid

[Tim Rentsch]

"Mehta Shailendrakumar" <sh*******************@de.bosch.com> writes:

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]

ya*******@gmail.com 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.

--
pete

[SM Ryan]

pete <pf*****@mindspring.com> wrote:
# ya*******@gmail.com 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.

--
SM Ryan http://www.rawbw.com/~wyrmwif/
God's a skeeball fanatic.

[Jean-Claude Arbaut]

Le 18/06/2005 15:53, dans 11*************@corp.supernews.com, «*SM Ryan*»
<wy*****@tango-sierra-oscar-foxtrot-tango.fake.org> a écrit*:

pete <pf*****@mindspring.com> wrote:
# ya*******@gmail.com 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'.

--
SM Ryan http://www.rawbw.com/~wyrmwif/
So....that would make Bethany part black?

[Jean-Claude Arbaut]

Le 18/06/2005 17:03, dans 11*************@corp.supernews.com, «*SM Ryan*»
<wy*****@tango-sierra-oscar-foxtrot-tango.fake.org> a écrit*:

# 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]

SM Ryan wrote:

# 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]

Martin Ambuhl wrote:

SM Ryan wrote:

# 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

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*

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

--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson

[Walter Roberson]

In article <42***************@yahoo.com>,
CBFalconer <cb********@worldnet.att.net> wrote:

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.

--
"I want to make sure [a user] can't get through ... an online
experience without hitting a Microsoft ad"
-- Steve Ballmer [Microsoft Chief Executive]

[Martijn]

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

[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??" :P

--
Martijn
http://www.sereneconcepts.nl