bit fields

I have been working on implementing bit fields for #ImportC, with invaluable help from Iain.

And I've learned an unexpected lesson. Bit fields with DMC and Microsoft VC are simple. Bit fields on clang and gcc are complicated and messy. I've had a hard time duplicating that behavior. Hence,

1. https://dlang.org/phobos/std_bitmanip.html#bitfields does not create bit fields that match gcc/clang behavior. Not at all.

2. It's unreasonable to expect users to figure out how to lay out bit fields. Heck, how gcc/clang do it is essentially undocumented. They should be able to use bit fields that "just work" with the associated C compiler. We should be doing the hard work of compatibility, not dumping it on users.

3. DasBetterC is not in a great place since it can't do matching bit fields.

4. D is supposed to have relatively seamless compatibility with C. But we've left users twisting in the wind with C bit fields.

But there is good news. The result of figuring out bit fields for ImportC is that the logic is already in the D compiler, and we merely have to "turn it on" and it will work for D. There'll be a bit of extra work to deny trying to take the address of a bit field, pass it by `ref`, etc., but not too bad.

I propose adding bit fields to D to resolve these problems.

There are other advantages, too. I often use bit flags:

    enum Flags { A = 1, B = 2, C = 4, D = 8 }

    Flags f;
    f |= Flags.A;
    f &= ~Flags.B;

but this is tedious, and so this often just winds up as:

    bool a, b, c, d;

which is expensive in memory. With bit fields it is:

    bool a:1, b:1, c:1, d:1;

If we do it right, the code will be the same as the Flags version, and we can just do away with the Flags declaration.

P.S. Since the DMD backend already does bit fields, it was pretty simple to hook that up with ImportC.

Thoughts welcome.

On Saturday, 28 August 2021 at 08:20:25 UTC, Walter Bright wrote: > I have been working on implementing bit fields for #ImportC, with invaluable help from Iain. > > > P.S. Since the DMD backend already does bit fields, it was pretty simple to hook that up with ImportC. > > Thoughts welcome. As someone who uses bitfields alot, YES Please! My current workaround was to keep some C files in my projects just to be able to use bitfields, this would allow me to go pure D! I didn't even bring it up as I thought it was a lost cause. One very happy user, Daniel N

On Saturday, 28 August 2021 at 08:20:25 UTC, Walter Bright wrote: > I have been working on implementing bit fields for #ImportC, with invaluable help from Iain. > > And I've learned an unexpected lesson. Bit fields with DMC and Microsoft VC are simple. Bit fields on clang and gcc are complicated and messy. I've had a hard time duplicating that behavior. A link to an article that demonstrates what kind of complexities are involved: http://jkz.wtf/bit-field-packing-in-gcc-and-clang -Johan

On Sunday, 29 August 2021 at 07:57:11 UTC, Johan wrote: > On Saturday, 28 August 2021 at 08:20:25 UTC, Walter Bright wrote: >> I have been working on implementing bit fields for #ImportC, with invaluable help from Iain. >> >> And I've learned an unexpected lesson. Bit fields with DMC and Microsoft VC are simple. Bit fields on clang and gcc are complicated and messy. I've had a hard time duplicating that behavior. > > A link to an article that demonstrates what kind of complexities are involved: http://jkz.wtf/bit-field-packing-in-gcc-and-clang > > -Johan I see more tests that can be added to the testsuite. ;-)

Another reason for D bit fields are the various C to D and C++ to D translators. It's an unreasonable burden on those translation developers to account for all the different undocumented bit field layout algorithms.

Forums