March 09

On Saturday, 9 March 2024 at 07:51:08 UTC, Walter Bright wrote:

>

The problem with implementation-defined layout is much more of a pedantic one than a pragmatic one, as I've explained elsewhere in this thread.

I've shown that it's a problem when using bit bitfields in D's very own standard library (std.internal.unicode_tables) and asked you to name one dub package that would benefit from D bit fields having C layout, which you didn't do.

March 09

On Saturday, 9 March 2024 at 09:41:22 UTC, Dennis wrote:

>

On Saturday, 9 March 2024 at 07:51:08 UTC, Walter Bright wrote:

>

The problem with implementation-defined layout is much more of a pedantic one than a pragmatic one, as I've explained elsewhere in this thread.

I've shown that it's a problem when using bit bitfields in D's very own standard library (std.internal.unicode_tables) and asked you to name one dub package that would benefit from D bit fields having C layout, which you didn't do.

Not on dub, but my closed source makes use of it. Vendor supplied register definitions uses bitfields with C semantics. Also IPC where client/server is written in different languages.

March 09

On Saturday, 9 March 2024 at 10:46:10 UTC, Daniel N wrote:

>

Not on dub, but my closed source makes use of it. Vendor supplied register definitions uses bitfields with C semantics. Also IPC where client/server is written in different languages.

That would be great material for the DIP. Can you give a link to such a register definition, and show what your current approach is to create C compatible bit fields for it in D?

March 09

On Saturday, 9 March 2024 at 10:56:33 UTC, Dennis wrote:

>

On Saturday, 9 March 2024 at 10:46:10 UTC, Daniel N wrote:

>

Not on dub, but my closed source makes use of it. Vendor supplied register definitions uses bitfields with C semantics. Also IPC where client/server is written in different languages.

That would be great material for the DIP. Can you give a link to such a register definition, and show what your current approach is to create C compatible bit fields for it in D?

The sdk license doesn't allow me to share the files.

But you can find similar code here...
https://www.renesas.com/us/en/document/apn/sh7450-groupsh7451-group-register-definition-header-file

Typically an union with a word sized member is combined with the bitfields to provide either atomic access or convenient access to the fields.

Without native D support, I just use C for the lowest layer instead.

March 09

On Thursday, 7 March 2024 at 22:28:34 UTC, Dennis wrote:

>

Why bow down to C and treat D as a second class citizen? The DIP should really substantiate this alleged importance of C-compatibility of non-ImportC D bitfields: Can you name at least one dub package that would benefit from bit fields with C-compatible layout?

Qt uses bitfields in some headers, e.g. here: https://github.com/qt/qtbase/blob/4e158f6bfa7d0747d8da70b3b15a44b52e35bb8a/src/corelib/kernel/qtimer.h#L239

My bindings emulate the bitfields with a single field and accessor functions: https://github.com/tim-dlang/dqt/blob/2afa4adcec0a6905b11256f403c6136277a6c96a/core/qt/core/timer.d#L217

Bitfields in D could be used instead, but they would need to be compatible with C++ for extern(C++) types.

Sometimes bitfield members are disabled with the preprocessor: https://github.com/qt/qtbase/blob/4e158f6bfa7d0747d8da70b3b15a44b52e35bb8a/src/corelib/time/qdatetime.h#L259
This could be translated to version statements in D.

Most of the times bitfields for Qt are not a big problem, because they are only private members of the types.

March 09

On Thursday, 7 March 2024 at 05:00:36 UTC, Richard (Rikki) Andrew Cattermole wrote:

>

"gdc/lcd are lumped together because they produce identical results on the same platform."

s/lcd/ldc/

No mention of alignment, total size or the offset.

Agree, the DIP should mention those. The implementation seems to give each bitfield of a set the same value:

struct S
{
    uint a:1,
         b:1,
         c:1;
}
static assert(S.b.alignof == 4);
static assert(S.b.offsetof == 0);
static assert(S.b.sizeof == 4);
>

Needs to mention atomics as not being supported.

Yes. Bitfield impl doesn't allow shared, static (or even const) storage classes.

>

No trait to detect a bit field (if its an alias, or by name), nor get its size. Kinda required, enough other things in the language can appear via an alias sequence or by allMembers that are not able to be taken as a pointer of.

Possibly this might be enough (using S above):

enum E
{
    a, b, c
}
struct U
{
    int i;
    alias i this;
    enum max = 2;
}
enum isBitfield(alias a) = __traits(isIntegral, typeof(a)) &&
    !is(typeof(a) == enum) && a.max <= uint.sizeof * 8;

static assert(isBitfield!(S.b));
static assert(!isBitfield!(E.b));
static assert(!isBitfield!(U()));
>

The ability to take an alias via getMember needs to be considered if its valid to do so.

No mention of tupleof either, what happens there?

Impl:

void main()
{
    S s;
    s.tupleof[1]++;
    __traits(getMember, s, "c")++;
    writeln(s.tupleof); // 011
}
>

No motivation for not including a D layout for it, instead of forcing everyone into an unpredictable layout that the system C compiler might be using. Moving us off the library type and into a language defined one that is predictable is quite attractive so there needs to be an argument against this.

Just to mention, the argument in the DIP was portability with C bitfields.

March 09

On Thursday, 7 March 2024 at 04:26:56 UTC, Walter Bright wrote:

>

https://github.com/WalterBright/documents/blob/master/bitfields.md

>

One cannot take a reference to or the address of a bitfield

Taking a ref is not detected yet:
https://issues.dlang.org/show_bug.cgi?id=24263

I was wondering how to read/write the bits of a bitfield set as their underlying type. So I tried putting a bitfield set inside an anonymous union:

import std.stdio;

struct S
{
    union
    {
        uint u;
        uint a:1,
             b:1,
             c:1;
    }
}
static assert(S.sizeof == 4);

void main()
{
    S s;
    s.tupleof.writeln(); // 0000
    s.u++;
    s.tupleof.writeln(); // 1111
}

I was a bit surprised that setting u to 1 sets all 3 bitfields to 1 as well - I was assuming the union had 2 uint members where the 2nd one didn't have a name. Then I realized I needed to put the bitfields inside an anonymous struct, because otherwise each one was a union member. Anyway doing that does work.

March 10
I've had a bit of thought about the ABI concerns of having multiple layouts possible.

I think its better to ignore the ABI altogether when changing it.

```d
import core.attributes : bitfieldlayout;

struct Foo {
	@bitfieldlayout("packed") {
		int bar:1;
		int zah:2;
	}
}
```

That'll also solve how do we add new ones that isn't C or packed.

C can be default, that need not be changed to something else.
March 11

On Thursday, 7 March 2024 at 04:26:56 UTC, Walter Bright wrote:

>

https://github.com/WalterBright/documents/blob/master/bitfields.md

Typo:

>

Abstract
This proposal is for supporting bitfields in C the same way they are supported in C.

March 11
On 3/11/2024 2:46 AM, Martin Tschierschke wrote:
> On Thursday, 7 March 2024 at 04:26:56 UTC, Walter Bright wrote:
>> https://github.com/WalterBright/documents/blob/master/bitfields.md
> 
> Typo:
>> Abstract
>> This proposal is for supporting bitfields in **C** the same way they are supported in **C**.
> 
> 
> 

haha