www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - D and memory mapped devices

reply 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
Jun 14
next sibling parent reply 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'?
Jun 14
parent 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
Jun 14
prev sibling next sibling parent 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
Jun 14
prev sibling parent 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.
Jun 14