September 15, 2002
I'd like add a meta-level to Mark's suggestions.  It would be great to be able to collect bits strewn across multiple physical hardware locations into a single item that may be modified as a whole.  For example, a 48-bit value may be split across multiple non-adjacent 32-bit hardware locations.  Being able to collect and manipulate those bits as a single "thing" would be a dream come true.

Worse yet are strongly inter-related bits strewn across multiple locations.  I'd prefer to manage them as a set via enum values.  But a single enum value can't directly work across multiple locations (without explicit user code support).  If D did this, I'd be in heaven.

I have also seen hardware that was "expanded" by the manufacturer.  Let's say a part had a 16-bit internal value that was expanded to 17 bits.  That 17th bit could land in any location within the part's address space!  Again, compiler support would be fantastic.

More and more we embedded programmers need to deal with long bit strings, such as are seen in I2C and SPI links, not to mention the behemoth bit collections present on any JTAG link.  Describing this structure as a single bit-based entity would be invaluable, since no specific mapping to the CPU memory layout would be needed (or, more precisely, it would be handled for us by the D compiler).

I would love it if I never had to slice, dice and reassemble another bit stream ever again.  Getting a bit-stream "almost right" is like being "a little pregnant".  It's an all-or-nothing proposition.


-BobC



Mark Evans wrote:

> >
> >In general, you're right. But I tend to think bits aren't too useful outside of arrays of bits, and so aren't worth the extra definitional and implementation effort. This is one area where I'd like to see how things evolve.
> >
>
> Walter,
>
> Yes arrays of bits are useful!  Anything to enhance the construction and use of bit-flags fields would be nice.
>
> The error-prone process of writing C preprocessor macros is a pain.  All that bit shifting and masking takes forever to get right.  How nice it would be for the language to offer direct constructs.
>
> I'd like specific keywords and language constructs for bitfields.  In particular, bitfields of arbitrarily large size.  They can be multiples of some integer size, but the point is to allow bitfields which exceed the size of one standard integer.  Say, a bitfield with 256 bits.
>
> Bitfields sometimes mix numbers with boolean bits, and the numbers can have arbitrary bit-sizes.  Two bits gives integers 0-3, etc.  This number sits between boolean bits in a common bitfield.
>
> For a language that aspires to be a systems language, these features would sure be cool.
>
> Come to that, what about hardware registers?  The D design-by-contract philosophy could be applied here.  Sometimes a register is read-only, sometimes write-only, and sometimes read-write.  Just depends on the hardware.  Sometimes a register may have a size not matching a multiple of some integer.  D should handle that.
>
> For example, I might have a register 8 bits wide which serves one major function in bits 0-2 and another entirely different function in bits 3-7.  The problem is all the masking to ensure that I don't hit 0-2 while exercising 3-7.  A systems language permitting me to define separate bit fields for these ranges would be a dream.
>
> Mark

September 15, 2002
Oh, I was trying to avoid bitfields <g>.

"Mark Evans" <Mark_member@pathlink.com> wrote in message news:am03uh$a7v$1@digitaldaemon.com...
>
> >
> >In general, you're right. But I tend to think bits aren't too useful
outside
> >of arrays of bits, and so aren't worth the extra definitional and implementation effort. This is one area where I'd like to see how things evolve.
> >
>
> Walter,
>
> Yes arrays of bits are useful!  Anything to enhance the construction and
use of
> bit-flags fields would be nice.
>
> The error-prone process of writing C preprocessor macros is a pain.  All
that
> bit shifting and masking takes forever to get right.  How nice it would be
for
> the language to offer direct constructs.
>
> I'd like specific keywords and language constructs for bitfields.  In particular, bitfields of arbitrarily large size.  They can be multiples of
some
> integer size, but the point is to allow bitfields which exceed the size of
one
> standard integer.  Say, a bitfield with 256 bits.
>
> Bitfields sometimes mix numbers with boolean bits, and the numbers can
have
> arbitrary bit-sizes.  Two bits gives integers 0-3, etc.  This number sits between boolean bits in a common bitfield.
>
> For a language that aspires to be a systems language, these features would
sure
> be cool.
>
> Come to that, what about hardware registers?  The D design-by-contract philosophy could be applied here.  Sometimes a register is read-only,
sometimes
> write-only, and sometimes read-write.  Just depends on the hardware.
Sometimes
> a register may have a size not matching a multiple of some integer.  D
should
> handle that.
>
> For example, I might have a register 8 bits wide which serves one major
function
> in bits 0-2 and another entirely different function in bits 3-7.  The
problem is
> all the masking to ensure that I don't hit 0-2 while exercising 3-7.  A
systems
> language permitting me to define separate bit fields for these ranges
would be a
> dream.
>
> Mark
>
>


September 15, 2002
I am glad to see this issue to be discussed again :-)

I'd like to vote on bit fields of arbitrary size.

In D the compiler could change the order of class members which is
completely acceptable (and conceptually clear) while we have to
consider classes (objects) as virtual entities.

In other hand struct members have fixed order and memory footprint since
we could order the compiler how to align these members. Structs are near
to the physical world. So it would be practical to have full control
over the struct layout. That means in a nearest-to-the-iron situation
(embedded controllers, device drivers, even in mixed platforms)
a real struct often has signed and unsigned bitfields, reserved
bits, enumerable numbers (unsigned integers), shifted values, connected
values etc.

These two approaches could live together without pain.

While one designs a system he/she uses virtual building blocks,
for example "objects/entities" whatever convetion we use.
When one implements the system in most every cases he/she must
comply with some existing structure.

The nearest thing to the objects could be a present D class (with interfaces). The nearest thing to the a physical footprint could be a well behaved struct.

(In the present days I write an XML-like translator which runs on PC and
produces binary output files/streams for embedded controllers (PIC&AVR).
I also have to rewrite an existing timer-executor program which runspresently
on PC, but it should be run on a bigger microcontroller. D would be nice for
these purposes and I use it already, but sometimes I feel it inconvenient.)

I am not sure that C style bit fields are the best implementation, but I feel the need for a construction like that.

May be Walter could offer an inexpensive or painless alternative.

Handling bits separately is an embedded problem. It would be nice to describe it with an universal language like D. But it is not the goal of a 32bit PC compiler to produce bitfield optimized code, I agree.

Best regards,
Tamás Nagy
(microwizard@ax.hu)


In article <am1f0s$1mvl$1@digitaldaemon.com>, Walter says...
>
>Oh, I was trying to avoid bitfields <g>.
>
>"Mark Evans" <Mark_member@pathlink.com> wrote in message news:am03uh$a7v$1@digitaldaemon.com...
>>
>> >
>> >In general, you're right. But I tend to think bits aren't too useful
>outside
>> >of arrays of bits, and so aren't worth the extra definitional and implementation effort. This is one area where I'd like to see how things evolve.
>> >
>>
>> Walter,
>>
>> Yes arrays of bits are useful!  Anything to enhance the construction and
>use of
>> bit-flags fields would be nice.
>>
>> The error-prone process of writing C preprocessor macros is a pain.  All
>that
>> bit shifting and masking takes forever to get right.  How nice it would be
>for
>> the language to offer direct constructs.
>>
>> I'd like specific keywords and language constructs for bitfields.  In particular, bitfields of arbitrarily large size.  They can be multiples of
>some
>> integer size, but the point is to allow bitfields which exceed the size of
>one
>> standard integer.  Say, a bitfield with 256 bits.
>>
>> Bitfields sometimes mix numbers with boolean bits, and the numbers can
>have
>> arbitrary bit-sizes.  Two bits gives integers 0-3, etc.  This number sits between boolean bits in a common bitfield.
>>
>> For a language that aspires to be a systems language, these features would
>sure
>> be cool.
>>
>> Come to that, what about hardware registers?  The D design-by-contract philosophy could be applied here.  Sometimes a register is read-only,
>sometimes
>> write-only, and sometimes read-write.  Just depends on the hardware.
>Sometimes
>> a register may have a size not matching a multiple of some integer.  D
>should
>> handle that.
>>
>> For example, I might have a register 8 bits wide which serves one major
>function
>> in bits 0-2 and another entirely different function in bits 3-7.  The
>problem is
>> all the masking to ensure that I don't hit 0-2 while exercising 3-7.  A
>systems
>> language permitting me to define separate bit fields for these ranges
>would be a
>> dream.
>>
>> Mark


September 16, 2002
"Walter" <walter@digitalmars.com> wrote in message news:als6mv$v08$1@digitaldaemon.com...
>
> "Pavel Minayev" <evilone@omen.ru> wrote in message news:alpvua$9jt$1@digitaldaemon.com...
> > Walter wrote:
> > > There's no simple way to take the address of a bit, and out parameters
> are
> > > implemented as pointers.
> > Just as bit arrays have separate implementation, so should do bit out parameters. Of course it will be more than just a pointer, but why should I care about it when I write code? bit shouldn't be lower-level than other types are, and out parameters are fundamental language construct. No pointers to bits sounds okay simply because pointers are too low-level themselves, but out parameters aren't restricted (or even specified) to be pointers!
>
> In general, you're right. But I tend to think bits aren't too useful
outside
> of arrays of bits, and so aren't worth the extra definitional and implementation effort. This is one area where I'd like to see how things evolve.

Bits aren't too useful outside of array of bits. Period.
But booleans are! They just want to be passed as an out parameter. And have
pointers to them. Please make boolean a native type. Do not make the mistake
of C again, by thinking of boolean as an integer. It is similar to lacking
pointers, and using integers for the purpose, just because they are the same
size.

Yours,
Sandor


September 16, 2002
D lacks a native boolean type?  Say it ain't so.  One of the best things that happened when C became C++ was the native 'bool' type.

Whatever happens with bitfields, a bool type seems an obvious necessity in a modern language.

Mark


September 16, 2002
Bitfields touch on D's charter.  If D wants to be a systems language then it should have them.  If it wants to be a "32bit PC compiler," then it can live without.

Either charter is valid, and both together is also valid (my preference!).
Bitfields could be postponed until a later revision (although it is nice to nail
down a spec early).

I liked the suggestion of gathering disparate bits across the system into one coherent structure.  That is interesting.  The point about a vendor's 16-bit register growing to 17 bits is answered by arbitrary-length bitfields, which I mentioned earlier.

Such odd-sized fields would not require structure packing down to the resolution of one bit.  One-byte resolution is enough.  The 17 bits could fit into a 24-bit or 32-bit span of memory.  Mainly the compiler must handle naming and accessing of particular bits (or mini-bit-fields) in some standardized fashion that eliminates preprocessor macros.  Basically I want to declare a 17-bit register and give each bit a name and an in-out-both-neither designation ('neither' applying by default to all out-of-bounds bits above the 17th out of the 24 or 32 allocated).

From an embedded standpoint the key thing is to start the bitfield at precisely the right hex address (byte resolution here).  This might be a function of the linker, not the compiler.  Some embedded tools require a "memory map" as an input to the link step.

The embedded market is pretty huge but the tools are bad.  Typically embedded development tools are half-baked at best.  I've done lots of C embedded work and would love to have D at my disposal.

Mark


> Handling bits separately is an embedded problem. It would be nice to describe it with an universal language like D. But it is not the goal of a 32bit PC compiler to produce bitfield optimized code, I agree.
>
> Best regards,
> Tamás Nagy
> (microwizard@ax.hu)
>>
>>Oh, I was trying to avoid bitfields <g>.



September 17, 2002
Mark Evans <Mark_member@pathlink.com> wrote in news:am5lqo$4gd$1@digitaldaemon.com:

> D lacks a native boolean type?  Say it ain't so.  One of the best things that happened when C became C++ was the native 'bool' type.
> 
> Whatever happens with bitfields, a bool type seems an obvious necessity in a modern language.
> 
> Mark

Probably a bool type is a good thing.  However nothing really needs to be done to the base compiler to make this happen. "typedef byte bool;" works well since D has fixed typedef. or "enum bool { true, false }"

It just need to be put into the base phobos distribution so that there is a common definition.


September 17, 2002
"Patrick Down" <pat@codemoon.com> wrote in message news:Xns928BC53833945patcodemooncom@63.105.9.61...
> Mark Evans <Mark_member@pathlink.com> wrote in news:am5lqo$4gd$1@digitaldaemon.com:
>
> > D lacks a native boolean type?  Say it ain't so.  One of the best things that happened when C became C++ was the native 'bool' type.
> >
> > Whatever happens with bitfields, a bool type seems an obvious necessity in a modern language.
> >
> > Mark
>
> Probably a bool type is a good thing.  However nothing really needs to be done to the base compiler to make this happen. "typedef byte bool;" works well since D has fixed typedef.

A typedef has implicit conversion in one direction. Bool should not have it.

> or "enum bool { true, false }"

I don't want to write:
bool a = bool.true;

So neither is good enough.

> It just need to be put into the base phobos distribution so that there is a common definition.





September 17, 2002
"Sandor Hojtsy" <hojtsy@index.hu> wrote in message news:am6ij6$11pl$1@digitaldaemon.com...
>
> "Patrick Down" <pat@codemoon.com> wrote in message news:Xns928BC53833945patcodemooncom@63.105.9.61...
> > Probably a bool type is a good thing.  However nothing really needs to be done to the base compiler to make this happen. "typedef byte bool;" works well since D has fixed typedef.
>
> A typedef has implicit conversion in one direction. Bool should not have
it.

Right.  Not only that, the comparison operators don't produce bool values.

> > or "enum bool { true, false }"
>
> I don't want to write:
> bool a = bool.true;
>
> So neither is good enough.

Strangely, that's exactly my argument against making enum values have a scope that's inside the enum name.  We cannot make a user defined enum that's *not* scope-qualified, and I think that sucks.

Sean


September 17, 2002
OK so long as this technique distinguishes between templated classes with bytes and bools as the template parameters.  I dislike the enum method, it's just a shade better than #define TRUE 1.

Maybe the thing to do is revisit the C++ standards committee's decision to incorporate bools into C++, and see whether the same arguments don't also apply to D (which is a "better C++").

Mark


In article <Xns928BC53833945patcodemooncom@63.105.9.61>, Patrick Down says...
>
>Mark Evans <Mark_member@pathlink.com> wrote in news:am5lqo$4gd$1@digitaldaemon.com:
>
>> D lacks a native boolean type?  Say it ain't so.  One of the best things that happened when C became C++ was the native 'bool' type.
>> 
>> Whatever happens with bitfields, a bool type seems an obvious necessity in a modern language.
>> 
>> Mark
>
>Probably a bool type is a good thing.  However nothing really needs to be done to the base compiler to make this happen. "typedef byte bool;" works well since D has fixed typedef. or "enum bool { true, false }"
>
>It just need to be put into the base phobos distribution so that there is a common definition.
>
>