Memory-mapped C++ objects non hardware members

Question

I am developing a driver for a piece of memory mapped hardware using C++ and I defined a class that represents this device. It looks something like this:

class device
{
method1();
method2();

private:
device_register reg1;
device_register reg2;

}

The class has two files: device.cpp and device.h. The member variables represent actual registers on the device itself. Now I want to define more members that are not actual registers on the device itself, but I cannot define them inside the class because if I do, they will be defined at the memory mapped location of the device, which could contain other devices/registers. if I define them as public, that breaks the standard layout and the class won't work anymore.

So what I did is that I defined them as global variables outside the class definition. The problem is if I define more than one object, they will all share these global variables, but I want each object to have its own, how can I do this?

Can you have two subclasses: `device_hw` and `device_sw`, then a `device` class that has one each of those subclasses? — Adrian Mole, Aug 06 '21 at 20:24
@AdrianMole I can but the other answer makes it easier. Thanks though. — effendi, Aug 12 '21 at 01:02

score 3 · Answer 1 · answered Aug 06 '21 at 20:27

Perhaps you can use a separate class with a pointer to current "device"


class device_glob {

private :
  device * mmaped_device;
  int other_attrib;
};

You can allocate in mmaped location the device in the ctor probably. And then you need to integrate this in whatever registry system you are using to get references/pointers to a device currently.

score 1 · Accepted Answer · answered Aug 06 '21 at 21:17

You should create a separate POD (Plain Old Data) struct for the registers, because a non-POD class/struct could ruin your memory mapping even without adding extra data members. In POD types, the offset of the first data member is guaranteed to be 0, which is what you need. In non-POD types this contract is not always followed, e.g. it may be disrupted by vtables or RTTI. True, you could dutifully avoid only the changes that would change the offset of the first data member, but a more robust solution is to stick to all the POD requirements so that the standard requires your compiler to do what you want.

The requirements for a POD type can be found at cppreference here, but an easy mnemonic is that a struct with nothing but native type members will always be POD.

You should also make sure the registers are marked "volatile," though I have a hunch that if you already have a special "device_register" typedef, it includes a volatile specifier. In which case, you don't need an extra one in your own struct.

Example:

struct MyPeripheralRegisters
{
volatile device_register reg1;
volatile device_register reg2;
};

class MyPeripheralDriver
{
private:
  MyPeripheralRegisters* hardware = MY_MEMORY_MAPPED_ADDR;
  int my_private_state;
public:
  void method1();
  void method2();
};

This pattern for memory mapped components is often used in embedded driver libraries, so it has the principle of least astonishment on its side.

That's what I wanted to do, and that's what I'll probably go for. But what if I don't have MY_MEMORY_MAPPED_ADDR? In my case, I would get that after enumerating the PCI bus. Can I just pass this address through the ctor? — effendi, Aug 06 '21 at 21:33
@effendi if the address is available immediately during initialization, ctor of MyPeripheralDriver would indeed be a good place to set the value of MyPeripheralDriver.hardware per RAII. the MyPeripheralRegisters struct is basically a decoder key - whenever you can obtain that pointer to the first register, you can store it as a pointer to MyPeripheralRegisters and get readable register accesses that way. (you may also be interested in "bit fields," which are an obscure bit of syntactic sugar to notate the meaning on individual bits.) — Willa, Aug 06 '21 at 23:09

Memory-mapped C++ objects non hardware members

2 Answers2