Extending Bitfields

[pyth...@gmail.com]

Hello everyone,

I've always been interested in embedded development and have gravitated towards using C++ for most of my projects in that area. As such, one thing I find myself doing pretty often is working with memory mapped devices. This usually involves doing a fair amount of bitshifting, and this can get rather tedious and error prone. I knew that there should be a better way, and so I developed some templates to automate all the bitshifting. Using this I was able to create a much nicer interface to memory mapped devices than the typical set of #defines provided by chip vendors (gist with an example: https://gist.github.com/LordPython/e9f58255ae8bee7102dc603d29bb919f).

Afterwards, I realized that I might be able to make this a lot simpler by using bitfields. And so I came up with this alternative prototype: https://gist.github.com/LordPython/0e9428c4d425a109d5a926ad1a7017c6. However, I have a few concerns with the bitfield approach:

1. They're not really portable as (at least as far as I know) the layout of bitfields is implementation defined.
2. Because the fields in a bitfield only have their size specified, making sure that fields are at the right offset can be kind of annoying

It seems to me that almost all the times I'd want to use bitfields are for things like this memory mapped IO where I care about the exact layout of the bits, but then it turns out that bitfields aren't particularly useful, because the layout isn't specified. Another use case I've had is in parsing binary messages when there are fields that are smaller than a byte packed together - again here the exact layout is crucial to correctness, and portability is potentially a much greater concern than when developing software for a specific embedded system.

In the past, I have had exactly one case I remember where I've used bitfields, and that was when I wanted to pack a bunch of different fields very tightly into a 64 bit object so I could use atomic operations instead of needing a mutex. In this case, bitfields made sense because I did not care at all how the bitfield was arranged, just that it was only 64 bits in size.

So, I got to thinking that it would be really nice if bitfields were extended so that you could specify an explicit offset and length for each field, as well as a total size for the bitfield as a whole, something that works similar to the way Ada's record representation clauses do (http://www.ada-auth.org/standards/rm12_w_tc1/html/RM-13-5-1.html#S0313).

Does anyone else think that this might be a worthwhile extension of the language? Or does an extension like this not really fit with the C++ memory model for similar reasons that packing structs hasn't become standardized?

Also out of curiosity, has anyone else seen other good uses for bitfields in their current sate?

- Joseph Martin

PS: The fact that my first example using templates compiles down to almost exactly the same code as the second example and to writing the assembly by hand is one of the biggest reasons I love C++ (it ends up with 2 more instructions for this example because of the way volatile works). Though I'm sure many people here feel the same way :P

[John McFarlane]

There's a related paper from Klemens Morgenstern which was discussed recently in Study Group 14 including in the forum [1]. Kvasir provides bitfields functionality specialized for embedded systems [2].

John

[1] https://groups.google.com/a/isocpp.org/d/msg/sg14/E_EKDsAgFq0/oaQP9gKkCQAJ
[2] https://github.com/kvasir-io/Kvasir

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposal...@isocpp.org.
To post to this group, send email to std-pr...@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/289ee4d8-01ce-4628-b788-0e128c8be2d9%40isocpp.org.

[Joseph Martin]

Ah yes, that's very much along the lines of what I'd be looking for, thanks for pointing it out. I think the main thing not present in that proposal is that ideally I'd want a way to specify the offset and length (or alternatively offset/start and end) instead of just the length because I find it less error prone when dealing with the specifications which are often bit 0 is this, bit 1 is that, bits 2-7 are that, etc.

[dgutson .]

(Sorry top posting since not following a particular answer)

This might also be relevant: our paper and the discussion.

https://wg21.cmeerw.net/ewg/issue122

To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.

To post to this group, send email to std-pr...@isocpp.org.

To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/de5bfa10-e0bf-4669-b6ef-bf008d6676a4%40isocpp.org.