• Russel Winder via Digitalmars-d-learn (31/31) Jun 14 2017 In C and C++ you often use bitfields to control devices with memory
• Rene Zwanenburg (5/9) Jun 14 2017 I've casted void buffers to structs containing bitfields to read
• Jacob Carlborg (11/14) Jun 14 2017 This bitfield discussion came up in a DStep issue [1]. The bitfields
• Steven Schveighoffer (7/28) Jun 14 2017 Why not? It should work just the same as C's bitfields, but with more
• Vladimir Panteleev (4/6) Jun 14 2017 I believe the only case where it might matter is if the device

Russel Winder via Digitalmars-d-learn <digitalmars-d-learn puremagic.com> writes:

In C and C++ you often use bitfields to control devices with memory
mapped hardware control and data words. So for example:

typedef struct some_device {
    unsigned int flob: 3;
    unsigned int adob: 2;
    unsigned int: 3;
    unsigned int data: 8;
} some_device;

Clearly D has no bitfields. I know of std.bitfield, so somethign like:

struct some_device {
    uint a;
    mixin(bitfields!(
        uint, "flob", 3,
        uint, "adob", 2,
        uint, "someMadeUpNameBecauseBlankIsNotAcceptable", 3,
        uint, "data", 8));
}

but the bitfields mixin template appears to do more than add all the
bit twiddling functions to emulate the bitfields. This would appear a
priori to not allow for actual memory mapped devices using it, or am I
missing something?=20

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

Rene Zwanenburg <renezwanenburg gmail.com> writes:

On Wednesday, 14 June 2017 at 08:10:57 UTC, Russel Winder wrote:
 but the bitfields mixin template appears to do more than add 
 all the bit twiddling functions to emulate the bitfields. This 
 would appear a priori to not allow for actual memory mapped 
 devices using it, or am I missing something?

I've casted void buffers to structs containing bitfields to read 
pre-existing binary files, and that worked just fine. I don't see 
why it would be different for memory mapped devices. What do yo 
mean by 'do more'?

Jacob Carlborg <doob me.com> writes:

On 2017-06-14 11:04, Rene Zwanenburg wrote:

 I've casted void buffers to structs containing bitfields to read
 pre-existing binary files, and that worked just fine. I don't see why it
 would be different for memory mapped devices. What do yo mean by 'do more'?

This bitfield discussion came up in a DStep issue [1]. The bitfields 
mixin will generate a field to store the bits in, which I think was 
surprising for Russel. Although, currently there are no other way to 
specify which other field should be used for storage.

Another issue that came up is that you can use the default generated 
constructor or the struct initializer syntax to bypass the generate 
methods and set the underlying storage field directly.

[1] https://github.com/jacob-carlborg/dstep/issues/151

-- 
/Jacob Carlborg

Steven Schveighoffer <schveiguy yahoo.com> writes:

On 6/14/17 4:10 AM, Russel Winder via Digitalmars-d-learn wrote:
 In C and C++ you often use bitfields to control devices with memory
 mapped hardware control and data words. So for example:

 typedef struct some_device {
     unsigned int flob: 3;
     unsigned int adob: 2;
     unsigned int: 3;
     unsigned int data: 8;
 } some_device;

 Clearly D has no bitfields. I know of std.bitfield, so somethign like:

 struct some_device {
     uint a;
     mixin(bitfields!(
         uint, "flob", 3,
         uint, "adob", 2,
         uint, "someMadeUpNameBecauseBlankIsNotAcceptable", 3,
         uint, "data", 8));
 }

 but the bitfields mixin template appears to do more than add all the
 bit twiddling functions to emulate the bitfields. This would appear a
 priori to not allow for actual memory mapped devices using it, or am I
 missing something?

Why not? It should work just the same as C's bitfields, but with more 
configurability. It all depends on how the hardware register works, as 
they often don't act like normal memory. One thing D does miss is the 
volatile keyword.

Have you tried it? It might just work :)

-Steve

Vladimir Panteleev <thecybershadow.lists gmail.com> writes:

On Wednesday, 14 June 2017 at 08:10:57 UTC, Russel Winder wrote:
 This would appear a priori to not allow for actual memory 
 mapped devices using it, or am I missing something?

I believe the only case where it might matter is if the device 
was sensitive to the read/write size (1/2/4 bytes). Otherwise, 
the generated code should be functionally the same as C bitfields.