bit fields (page 2)

On Sunday, 29 August 2021 at 15:09:14 UTC, Iain Buclaw wrote: > 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. ;-) I think it's worthwhile to create a random testcase generator and let it run (+ execute the test) for a day or two... -Johan

August 30, 2021

Re: bit fields

Posted by Johan
in reply to Iain Buclaw

Permalink

Johan

Posted in reply to Iain Buclaw

Permalink

On Monday, 30 August 2021 at 11:07:31 UTC, Iain Buclaw wrote:

On Monday, 30 August 2021 at 10:43:33 UTC, Steven Schveighoffer wrote:

On 8/30/21 6:40 AM, Johan wrote:

I think it's worthwhile to create a random testcase generator and let it run (+ execute the test) for a day or two...

Max had said he was going to try and cobble something like this together during beerconf.

I had raised a bug report about doing such a thing a couple months back too.

https://issues.dlang.org/show_bug.cgi?id=22074

Something like that, but then specific for bit fields that includes execution of C/D code, something like this:

Randomly generate C file with a struct+bitfields type definition:

struct Test {
  {<empty>|some __alignment...} {<empty>|signed|unsigned} {int|char|long|size_t|float|...} member1 {<empty>|:<some number 0..bitwidth of the storage type};
  ... repeat for member2, member3, random number of members
}

void resetMember1_C(Test* t)
{
  t->member1 = 0;
}
...repeat for how many members there are

size_t sizeofTest_C()
{
   return sizeof(Test);
}

While generating the C file, you also generate a D file:

extern(C)
struct Test {
// ofcourse corresponding to the generated C type!
  {<empty>|align(...)} {int|uint|bool|byte|char|long|size_t|float|...} member1 {<empty>|:<some number 0..bitwidth of the storage type};
  ... repeat for member2, member3, random number of members
}

extern(C) void resetMember1_C(Test* t);
void resetMember1_D(Test* t)
{
  t.member1 = 0;
}
...repeat for how many members there are

extern(C) size_t sizeofTest_C();
size_t sizeofTest_D()
{
   return Test.sizeof();
}

void main()
{
  assert(sizeofTest_C() == sizeofTest_D());

  foreach(i; number of members in Test) {
     Test s_C;
     Test s_D;
     memset(&s_C, 0xFF, Test.sizeof);
     memset(&s_D, 0xFF, Test.sizeof);
     resetMemberi_C(&s_C);
     resetMemberi_D(&s_D);
     assert(memcmp(&s_C, &s_D, Test.sizeof));
  }
}

Compile and run at -O0 and -O3 on every arch supported. Make sure that asserts are not discarded at high optimization level.

And then loop&repeat these steps for a long time.

cheers,
Johan

On 8/29/2021 11:32 PM, Elronnd wrote: > On Saturday, 28 August 2021 at 08:20:25 UTC, Walter Bright wrote: >> how gcc/clang do it is essentially undocumented > > x86-64-psABI, sec 3.1.2 (data representation) https://github.com/hjl-tools/x86-psABI/wiki/x86-64-psABI-1.0.pdf That only partially documents it. It doesn't cover things like alignment and 0 length fields.

On Monday, 30 August 2021 at 18:39:20 UTC, Walter Bright wrote: > On 8/29/2021 11:32 PM, Elronnd wrote: >> On Saturday, 28 August 2021 at 08:20:25 UTC, Walter Bright wrote: >>> how gcc/clang do it is essentially undocumented >> >> x86-64-psABI, sec 3.1.2 (data representation) > > https://github.com/hjl-tools/x86-psABI/wiki/x86-64-psABI-1.0.pdf > > That only partially documents it. It doesn't cover things like alignment and 0 length fields. Zero-length bitfields are covered by the C standard: > As a special case, a bit-field structure member with a width of 0 indicates that no further bit-field is to be packed into the unit in which the previous bit-field, if any, was placed. Source: http://port70.net/~nsz/c/c99/n1256.html#6.7.2.1p11

On 28.08.21 10:20, Walter Bright wrote: > > 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; +1. This is one of those things you leave in to fix later because the syntax is more convenient, then it does not get fixed later.

Forums