I remember read D's introduction page that C's bit field is something will be dropped from D.

But now I see dmd/src/phobos/std/bitmanip.d line 30 ~ 98: bit field functions are generated at compile time,

private template createAccessors(...) {
  // getter
  // setter
  ...
}

I wonder how efficient is this. If we are going to have bit fields in the *std* library, why not support it properly in the language. I think the compiler can generate much better code than these compile-time generated functions, which looks like a hack to me.

comments?

nobody wrote:
> I remember read D's introduction page that C's bit field is something will be dropped from D.
> 
> But now I see dmd/src/phobos/std/bitmanip.d line 30 ~ 98: bit field functions are generated at compile time,
> 
> private template createAccessors(...) {
>   // getter
>   // setter
>   ...
> }
> 
> I wonder how efficient is this. If we are going to have bit fields in the *std* library, why not support it properly in the language. I think the compiler can generate much better code than these compile-time generated functions, which looks like a hack to me.
> 
> comments?

The auto-generated code from the library is the same code the compiler would end up generating.  You can test that theory by comparing the produced assembly for a C vs a D implementation.

Later,
Brad

== Quote from Brad Roberts (braddr@puremagic.com)'s article
> The auto-generated code from the library is the same code the compiler would end up generating.  You can test that theory by comparing the produced assembly for a C vs a D implementation.

If the generated code are same, and it's in the std library, which means no difference in the backend.

Then I'd rather write:

struct A
{
        bool flag1:  1;
        bool flag2:  1;
        // uint "",  6;   // this should be auto-magically generated by the compiler
}

(the code is more clear, and the compiler can give better message).

than this:

struct A
{
    mixin(bitfields!(
        bool, "flag1",    1,
        bool, "flag2",    1,
        uint, "",         6));
}

nobody wrote:
> == Quote from Brad Roberts (braddr@puremagic.com)'s article
>> The auto-generated code from the library is the same code the compiler would end up generating.  You can test that theory by comparing the produced assembly for a C vs a D implementation.
> 
> If the generated code are same, and it's in the std library, which means no difference in the backend.
> 
> Then I'd rather write:
> 
> struct A
> {
>         bool flag1:  1;
>         bool flag2:  1;
>         // uint "",  6;   // this should be auto-magically generated by the compiler
> }
> 
> (the code is more clear, and the compiler can give better message).
> 
> than this:
> 
> struct A
> {
>     mixin(bitfields!(
>         bool, "flag1",    1,
>         bool, "flag2",    1,
>         uint, "",         6));
> }

Except that bitfields don't appear to be a widely used feature.  If you can put it in the library with no performance penalty AND simplify the compiler at the same time, that looks like a good thing to me, and I believe Walter agrees.

  -- Daniel

nobody wrote:
> == Quote from Brad Roberts (braddr@puremagic.com)'s article
>> The auto-generated code from the library is the same code the compiler
>> would end up generating.  You can test that theory by comparing the
>> produced assembly for a C vs a D implementation.
> 
> If the generated code are same, and it's in the std library, which means no
> difference in the backend.
> 
> Then I'd rather write:
> 
> struct A
> {
>         bool flag1:  1;
>         bool flag2:  1;
>         // uint "",  6;   // this should be auto-magically generated by the compiler
> }
> 
> (the code is more clear, and the compiler can give better message).
> 
> than this:
> 
> struct A
> {
>     mixin(bitfields!(
>         bool, "flag1",    1,
>         bool, "flag2",    1,
>         uint, "",         6));
> }

Bitfields are a rather obscure feature. There's no real reason to have it in the compiler. But because D is so great, you still can have it in the standard library. Sadly, this comes with a bit more ugly syntax. If we had macros (which were ditched for the oh-so-great [actually questionable] features const and immutable), then it could be at least a _bit_ more beautiful. Like defining identifiers as identifiers, and not strings.

What I'm really concerned about is that this mixin MAGICALLY inserts unknown symbols into the current scope. I was too lazy to look in the Phobos code, but it's clear that the mixin must generate "hidden" fields to store the actual bit values. (With a bit of luck, the author [Andrei?] was careful enough to allow several bitfield mixins in the same struct.) I also will blow up if later you add serialization or anything in this direction.

A clean way would to to let the bitfields thing generate a real struct type:


alias Bitfields!(bool, "flag1", 1, bool, "flag2", 6) MyBitfields;

No more magical insertion of identifiers into your code. And a serialization mechanism just could detect the type Bitfields and write its actual members, and not the hidden bit array field (or whatever the implementation uses, it just insert its own, unknown-to-you symbols into YOUR scope).

Daniel Keep wrote:
> 
> nobody wrote:
>> == Quote from Brad Roberts (braddr@puremagic.com)'s article
>>> The auto-generated code from the library is the same code the compiler
>>> would end up generating.  You can test that theory by comparing the
>>> produced assembly for a C vs a D implementation.
>> If the generated code are same, and it's in the std library, which means no
>> difference in the backend.
>>
>> Then I'd rather write:
>>
>> struct A
>> {
>>         bool flag1:  1;
>>         bool flag2:  1;
>>         // uint "",  6;   // this should be auto-magically generated by the compiler
>> }
>>
>> (the code is more clear, and the compiler can give better message).
>>
>> than this:
>>
>> struct A
>> {
>>     mixin(bitfields!(
>>         bool, "flag1",    1,
>>         bool, "flag2",    1,
>>         uint, "",         6));
>> }
> 
> Except that bitfields don't appear to be a widely used feature.  If you
> can put it in the library with no performance penalty AND simplify the
> compiler at the same time, that looks like a good thing to me, and I
> believe Walter agrees.

Yeah, let's move everything from the compiler to the library. Damn, why couldn't they have const implemented as library feature?

>   -- Daniel

grauzone wrote:
> Daniel Keep wrote:
>>
>> nobody wrote:
>>> == Quote from Brad Roberts (braddr@puremagic.com)'s article
>>>> The auto-generated code from the library is the same code the compiler would end up generating.  You can test that theory by comparing the produced assembly for a C vs a D implementation.
>>> If the generated code are same, and it's in the std library, which
>>> means no
>>> difference in the backend.
>>>
>>> Then I'd rather write:
>>>
>>> struct A
>>> {
>>>         bool flag1:  1;
>>>         bool flag2:  1;
>>>         // uint "",  6;   // this should be auto-magically generated
>>> by the compiler
>>> }
>>>
>>> (the code is more clear, and the compiler can give better message).
>>>
>>> than this:
>>>
>>> struct A
>>> {
>>>     mixin(bitfields!(
>>>         bool, "flag1",    1,
>>>         bool, "flag2",    1,
>>>         uint, "",         6));
>>> }
>>
>> Except that bitfields don't appear to be a widely used feature.  If you can put it in the library with no performance penalty AND simplify the compiler at the same time, that looks like a good thing to me, and I believe Walter agrees.
> 
> Yeah, let's move everything from the compiler to the library. Damn, why couldn't they have const implemented as library feature?
> 
>>   -- Daniel

Except that bitfields don't appear to be a widely used feature.

  -- Daniel

Daniel Keep:
> Except that bitfields don't appear to be a widely used feature.

I have found plenty of them in code to translate from C to other languages.

Another possible solution is the same intermediate one that will be used for the associative arrays: keep only the syntax in the language and implement their semantics in the std lib.

Bye,
bearophile

> Except that bitfields don't appear to be a widely used feature.

You clearly have not written systems code in Ada... :)

C-bitfields are problematic because the bit-ordering is implementation defined, GCC have the bits appear in the order of definition on big-endian machines and the reverse order on little endian machines. The appropriate way is to have them as the big-endian fields in GCC, this is also what most Ada-compilers seem to be doing.

They are incredibly useful for any systems and protocol programming, and this is why they are nice to have in a language like D.

Bitfields are not used in C because they are not platform neutral, a proper definition in D would mean that people would use them, at least in the mentioned domains.

/ Mattias

Mattias Holm:
> You clearly have not written systems code in Ada... :)

Bitfields are quite useful, also take a look at the high level language Erlang, that has some high-level ways to use them. In the end the current design of D2 bitfields is acceptable. Inecessary some syntax sugar can be added later, as macro form.

Bye,
bearophile