Topic: Extending Bitfields
Author: pythoner6@gmail.com
Date: Sat, 24 Jun 2017 20:41:20 -0700 (PDT)
Raw View
------=_Part_1372_1791096360.1498362080162
Content-Type: multipart/alternative;
boundary="----=_Part_1373_632297042.1498362080162"
------=_Part_1373_632297042.1498362080162
Content-Type: text/plain; charset="UTF-8"
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
--
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-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@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.
------=_Part_1373_632297042.1498362080162
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Hello everyone,<div><br></div><div>I've always been in=
terested 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 pr=
etty often is working with memory mapped devices. This usually involves doi=
ng 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 te=
mplates 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 #defi=
nes provided by chip vendors (gist with an example: https://gist.github.com=
/LordPython/e9f58255ae8bee7102dc603d29bb919f).</div><div><br></div><div>Aft=
erwards, I realized that I might be able to make this a lot simpler by usin=
g bitfields. And so I came up with this alternative prototype:=C2=A0https:/=
/gist.github.com/LordPython/0e9428c4d425a109d5a926ad1a7017c6. However, I ha=
ve a few concerns with the bitfield approach:</div><div><ol><li>They're=
not really portable as (at least as far as I know) the layout of bitfields=
is implementation defined.</li><li>Because the fields in a bitfield only h=
ave their size specified, making sure that fields are at the right offset c=
an be kind of annoying</li></ol></div><div>It seems to me that almost all t=
he times I'd want to use bitfields are for things like this memory mapp=
ed IO where I care about the exact layout of the bits, but then it turns ou=
t that bitfields aren't particularly useful, because the layout isn'=
;t specified. Another use case I've had is in parsing binary messages w=
hen there are fields that are smaller than a byte packed together - again h=
ere the exact layout is crucial to correctness, and portability is potentia=
lly a much greater concern than when developing software for a specific emb=
edded system.</div><div><br></div><div>In the past, I have had exactly one =
case I remember where I've used bitfields, and that was when I wanted t=
o pack a bunch of different fields very tightly into a 64 bit object so I c=
ould use atomic operations instead of needing a mutex. In this case, bitfie=
lds made sense because I did not care at all how the bitfield was arranged,=
just that it was only 64 bits in size.</div><div><br></div><div>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).</div><div><br></div><div>=
Does anyone else think that this might be a worthwhile extension of the lan=
guage? Or does an extension like this not really fit with the C++ memory mo=
del for similar reasons that packing structs hasn't become standardized=
?</div><div><br></div><div>Also out of curiosity, has anyone else seen othe=
r good uses for bitfields in their current sate?</div><div><br></div><div>-=
Joseph Martin</div><div><br></div><div>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 sam=
e way :P</div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/289ee4d8-01ce-4628-b788-0e128c8be2d9%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/289ee4d8-01ce-4628-b788-0e128c8be2d9=
%40isocpp.org</a>.<br />
------=_Part_1373_632297042.1498362080162--
------=_Part_1372_1791096360.1498362080162--
.
Author: John McFarlane <john@mcfarlane.name>
Date: Sun, 25 Jun 2017 05:07:41 +0000
Raw View
--001a113eb1c401e9510552c1d179
Content-Type: text/plain; charset="UTF-8"
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
On Sat, Jun 24, 2017 at 8:41 PM <pythoner6@gmail.com> wrote:
> 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
>
> --
> 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-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@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
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/289ee4d8-01ce-4628-b788-0e128c8be2d9%40isocpp.org?utm_medium=email&utm_source=footer>
> .
>
--
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-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CABPJVnTemri7jarrF9HVQtRcstyj5E6CEex43X2S9RcM3sFLMw%40mail.gmail.com.
--001a113eb1c401e9510552c1d179
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>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=
].<br><br></div>John<br><div><br>[1] <a href=3D"https://groups.google.com/a=
/isocpp.org/d/msg/sg14/E_EKDsAgFq0/oaQP9gKkCQAJ">https://groups.google.com/=
a/isocpp.org/d/msg/sg14/E_EKDsAgFq0/oaQP9gKkCQAJ</a><br>[2] <a href=3D"http=
s://github.com/kvasir-io/Kvasir">https://github.com/kvasir-io/Kvasir</a><br=
></div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr">On Sat, Jun 24=
, 2017 at 8:41 PM <<a href=3D"mailto:pythoner6@gmail.com">pythoner6@gmai=
l.com</a>> wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"lt=
r">Hello everyone,<div><br></div><div>I've always been interested in em=
bedded development and have gravitated towards using C++ for most of my pro=
jects 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 amou=
nt 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 aut=
omate all the bitshifting. Using this I was able to create a much nicer int=
erface to memory mapped devices than the typical set of #defines provided b=
y chip vendors (gist with an example: <a href=3D"https://gist.github.com/Lo=
rdPython/e9f58255ae8bee7102dc603d29bb919f" target=3D"_blank">https://gist.g=
ithub.com/LordPython/e9f58255ae8bee7102dc603d29bb919f</a>).</div><div><br><=
/div><div>Afterwards, I realized that I might be able to make this a lot si=
mpler by using bitfields. And so I came up with this alternative prototype:=
=C2=A0<a href=3D"https://gist.github.com/LordPython/0e9428c4d425a109d5a926a=
d1a7017c6" target=3D"_blank">https://gist.github.com/LordPython/0e9428c4d42=
5a109d5a926ad1a7017c6</a>. However, I have a few concerns with the bitfield=
approach:</div><div><ol><li>They're not really portable as (at least a=
s far as I know) the layout of bitfields is implementation defined.</li><li=
>Because the fields in a bitfield only have their size specified, making su=
re that fields are at the right offset can be kind of annoying</li></ol></d=
iv><div>It seems to me that almost all the times I'd want to use bitfie=
lds 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 particu=
larly useful, because the layout isn't specified. Another use case I=
9;ve had is in parsing binary messages when there are fields that are small=
er than a byte packed together - again here the exact layout is crucial to =
correctness, and portability is potentially a much greater concern than whe=
n developing software for a specific embedded system.</div><div><br></div><=
div>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 ca=
re at all how the bitfield was arranged, just that it was only 64 bits in s=
ize.</div><div><br></div><div>So, I got to thinking that it would be really=
nice if bitfields were extended so that you could specify an explicit offs=
et 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 representa=
tion clauses do (<a href=3D"http://www.ada-auth.org/standards/rm12_w_tc1/ht=
ml/RM-13-5-1.html#S0313" target=3D"_blank">http://www.ada-auth.org/standard=
s/rm12_w_tc1/html/RM-13-5-1.html#S0313</a>).</div><div><br></div><div>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 f=
or similar reasons that packing structs hasn't become standardized?</di=
v><div><br></div><div>Also out of curiosity, has anyone else seen other goo=
d uses for bitfields in their current sate?</div><div><br></div><div>- Jose=
ph Martin</div><div><br></div><div>PS: The fact that my first example using=
templates compiles down to almost exactly the same code as the second exam=
ple and to writing the assembly by hand is one of the biggest reasons I lov=
e 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</div></div>
<p></p>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/289ee4d8-01ce-4628-b788-0e128c8be2d9%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/289ee4d8-01ce-=
4628-b788-0e128c8be2d9%40isocpp.org</a>.<br>
</blockquote></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CABPJVnTemri7jarrF9HVQtRcstyj5E6CEex4=
3X2S9RcM3sFLMw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CABPJVnTemri7jarr=
F9HVQtRcstyj5E6CEex43X2S9RcM3sFLMw%40mail.gmail.com</a>.<br />
--001a113eb1c401e9510552c1d179--
.
Author: Joseph Martin <pythoner6@gmail.com>
Date: Sat, 24 Jun 2017 22:46:58 -0700 (PDT)
Raw View
------=_Part_1457_573946451.1498369618518
Content-Type: multipart/alternative;
boundary="----=_Part_1458_1801156048.1498369618519"
------=_Part_1458_1801156048.1498369618519
Content-Type: text/plain; charset="UTF-8"
On Sunday, June 25, 2017 at 1:07:54 AM UTC-4, John McFarlane wrote:
>
> 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
>
> On Sat, Jun 24, 2017 at 8:41 PM <pyth...@gmail.com <javascript:>> wrote:
>
>> 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
>>
>> --
>> 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 <javascript:>.
>> To post to this group, send email to std-pr...@isocpp.org <javascript:>.
>> 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
>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/289ee4d8-01ce-4628-b788-0e128c8be2d9%40isocpp.org?utm_medium=email&utm_source=footer>
>> .
>>
>
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.
--
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-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@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.
------=_Part_1458_1801156048.1498369618519
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Sunday, June 25, 2017 at 1:07:54 AM UTC-4, John McFarla=
ne wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: =
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div=
>There's a related paper from Klemens Morgenstern which was discussed r=
ecently in Study Group 14 including in the forum [1]. Kvasir provides bitfi=
elds functionality specialized for embedded systems [2].<br><br></div>John<=
br><div><br>[1] <a href=3D"https://groups.google.com/a/isocpp.org/d/msg/sg1=
4/E_EKDsAgFq0/oaQP9gKkCQAJ" target=3D"_blank" rel=3D"nofollow" onmousedown=
=3D"this.href=3D'https://groups.google.com/a/isocpp.org/d/msg/sg14/E_EK=
DsAgFq0/oaQP9gKkCQAJ';return true;" onclick=3D"this.href=3D'https:/=
/groups.google.com/a/isocpp.org/d/msg/sg14/E_EKDsAgFq0/oaQP9gKkCQAJ';re=
turn true;">https://groups.google.com/a/<wbr>isocpp.org/d/msg/sg14/E_<wbr>E=
KDsAgFq0/oaQP9gKkCQAJ</a><br>[2] <a href=3D"https://github.com/kvasir-io/Kv=
asir" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D'ht=
tps://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fkvasir-io%2FKvasir=
\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNE0Kw5BF72S_rLz4jNQ2_7mxAEXdg';=
return true;" onclick=3D"this.href=3D'https://www.google.com/url?q\x3dh=
ttps%3A%2F%2Fgithub.com%2Fkvasir-io%2FKvasir\x26sa\x3dD\x26sntz\x3d1\x26usg=
\x3dAFQjCNE0Kw5BF72S_rLz4jNQ2_7mxAEXdg';return true;">https://github.co=
m/kvasir-io/<wbr>Kvasir</a><br></div></div><br><div class=3D"gmail_quote"><=
div dir=3D"ltr">On Sat, Jun 24, 2017 at 8:41 PM <<a href=3D"javascript:"=
target=3D"_blank" gdf-obfuscated-mailto=3D"LafT_jh3AQAJ" rel=3D"nofollow" =
onmousedown=3D"this.href=3D'javascript:';return true;" onclick=3D"t=
his.href=3D'javascript:';return true;">pyth...@gmail.com</a>> wr=
ote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;=
border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">Hello everyon=
e,<div><br></div><div>I've always been interested in embedded developme=
nt and have gravitated towards using C++ for most of my projects in that ar=
ea. As such, one thing I find myself doing pretty often is working with mem=
ory mapped devices. This usually involves doing a fair amount of bitshiftin=
g, and this can get rather tedious and error prone. I knew that there shoul=
d be a better way, and so I developed some templates to automate all the bi=
tshifting. 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: <a href=3D"https://gist.github.com/LordPython/e9f5825=
5ae8bee7102dc603d29bb919f" target=3D"_blank" rel=3D"nofollow" onmousedown=
=3D"this.href=3D'https://www.google.com/url?q\x3dhttps%3A%2F%2Fgist.git=
hub.com%2FLordPython%2Fe9f58255ae8bee7102dc603d29bb919f\x26sa\x3dD\x26sntz\=
x3d1\x26usg\x3dAFQjCNGcCjLbyYQ4GlHuaXfIDL47xL5crw';return true;" onclic=
k=3D"this.href=3D'https://www.google.com/url?q\x3dhttps%3A%2F%2Fgist.gi=
thub.com%2FLordPython%2Fe9f58255ae8bee7102dc603d29bb919f\x26sa\x3dD\x26sntz=
\x3d1\x26usg\x3dAFQjCNGcCjLbyYQ4GlHuaXfIDL47xL5crw';return true;">https=
://gist.github.com/<wbr>LordPython/<wbr>e9f58255ae8bee7102dc603d29bb91<wbr>=
9f</a>).</div><div><br></div><div>Afterwards, I realized that I might be ab=
le to make this a lot simpler by using bitfields. And so I came up with thi=
s alternative prototype:=C2=A0<a href=3D"https://gist.github.com/LordPython=
/0e9428c4d425a109d5a926ad1a7017c6" target=3D"_blank" rel=3D"nofollow" onmou=
sedown=3D"this.href=3D'https://www.google.com/url?q\x3dhttps%3A%2F%2Fgi=
st.github.com%2FLordPython%2F0e9428c4d425a109d5a926ad1a7017c6\x26sa\x3dD\x2=
6sntz\x3d1\x26usg\x3dAFQjCNFsFqjOZmvwO0jetN8DpyghW-pqdw';return true;" =
onclick=3D"this.href=3D'https://www.google.com/url?q\x3dhttps%3A%2F%2Fg=
ist.github.com%2FLordPython%2F0e9428c4d425a109d5a926ad1a7017c6\x26sa\x3dD\x=
26sntz\x3d1\x26usg\x3dAFQjCNFsFqjOZmvwO0jetN8DpyghW-pqdw';return true;"=
>https://gist.<wbr>github.com/LordPython/<wbr>0e9428c4d425a109d5a926ad1a701=
7<wbr>c6</a>. However, I have a few concerns with the bitfield approach:</d=
iv><div><ol><li>They're not really portable as (at least as far as I kn=
ow) the layout of bitfields is implementation defined.</li><li>Because the =
fields in a bitfield only have their size specified, making sure that field=
s are at the right offset can be kind of annoying</li></ol></div><div>It se=
ems to me that almost all the times I'd want to use bitfields are for t=
hings 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 i=
n parsing binary messages when there are fields that are smaller than a byt=
e 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.</div><div><br></div><div>In the pa=
st, I have had exactly one case I remember where I've used bitfields, a=
nd 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.</div><di=
v><br></div><div>So, I got to thinking that it would be really nice if bitf=
ields 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, somet=
hing that works similar to the way Ada's record representation clauses =
do (<a href=3D"http://www.ada-auth.org/standards/rm12_w_tc1/html/RM-13-5-1.=
html#S0313" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D&=
#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.ada-auth.org%2Fstandard=
s%2Frm12_w_tc1%2Fhtml%2FRM-13-5-1.html%23S0313\x26sa\x3dD\x26sntz\x3d1\x26u=
sg\x3dAFQjCNGIp1Y-Z8cCaT3trPJpbtgDPH-lqg';return true;" onclick=3D"this=
..href=3D'http://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.ada-auth.org%2=
Fstandards%2Frm12_w_tc1%2Fhtml%2FRM-13-5-1.html%23S0313\x26sa\x3dD\x26sntz\=
x3d1\x26usg\x3dAFQjCNGIp1Y-Z8cCaT3trPJpbtgDPH-lqg';return true;">http:/=
/www.ada-auth.org/<wbr>standards/rm12_w_tc1/html/RM-<wbr>13-5-1.html#S0313<=
/a>).</div><div><br></div><div>Does anyone else think that this might be a =
worthwhile extension of the language? Or does an extension like this not re=
ally fit with the C++ memory model for similar reasons that packing structs=
hasn't become standardized?</div><div><br></div><div>Also out of curio=
sity, has anyone else seen other good uses for bitfields in their current s=
ate?</div><div><br></div><div>- Joseph Martin</div><div><br></div><div>PS: =
The fact that my first example using templates compiles down to almost exac=
tly 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 instructi=
ons for this example because of the way volatile works). Though I'm sur=
e many people here feel the same way :P</div></div>
<p></p>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"=
LafT_jh3AQAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D'javascript:&=
#39;;return true;" onclick=3D"this.href=3D'javascript:';return true=
;">std-proposal...@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"javascript:" target=3D"_bla=
nk" gdf-obfuscated-mailto=3D"LafT_jh3AQAJ" rel=3D"nofollow" onmousedown=3D"=
this.href=3D'javascript:';return true;" onclick=3D"this.href=3D'=
;javascript:';return true;">std-pr...@isocpp.org</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/289ee4d8-01ce-4628-b788-0e128c8be2d9%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank" =
rel=3D"nofollow" onmousedown=3D"this.href=3D'https://groups.google.com/=
a/isocpp.org/d/msgid/std-proposals/289ee4d8-01ce-4628-b788-0e128c8be2d9%40i=
socpp.org?utm_medium\x3demail\x26utm_source\x3dfooter';return true;" on=
click=3D"this.href=3D'https://groups.google.com/a/isocpp.org/d/msgid/st=
d-proposals/289ee4d8-01ce-4628-b788-0e128c8be2d9%40isocpp.org?utm_medium\x3=
demail\x26utm_source\x3dfooter';return true;">https://groups.google.com=
/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/289ee4d8-01ce-4628-<wbr>b788-=
0e128c8be2d9%40isocpp.org</a><wbr>.<br></blockquote></div></blockquote><div=
><br></div><div>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 pr=
esent in that proposal is that ideally I'd want a way to specify the of=
fset and length (or alternatively offset/start and end) instead of just the=
length because I find it less error prone when dealing with the specificat=
ions which are often bit 0 is this, bit 1 is that, bits 2-7 are that, etc.<=
/div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/de5bfa10-e0bf-4669-b6ef-bf008d6676a4%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/de5bfa10-e0bf-4669-b6ef-bf008d6676a4=
%40isocpp.org</a>.<br />
------=_Part_1458_1801156048.1498369618519--
------=_Part_1457_573946451.1498369618518--
.
Author: "dgutson ." <danielgutson@gmail.com>
Date: Sun, 25 Jun 2017 08:44:49 -0300
Raw View
--001a114e1d82a5eb2b0552c75ca4
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
(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
El 25 jun. 2017 2:47 a. m., "Joseph Martin" <pythoner6@gmail.com> escribi=
=C3=B3:
> On Sunday, June 25, 2017 at 1:07:54 AM UTC-4, John McFarlane wrote:
>>
>> 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_EKDsAgFq
>> 0/oaQP9gKkCQAJ
>> [2] https://github.com/kvasir-io/Kvasir
>>
>> On Sat, Jun 24, 2017 at 8:41 PM <pyth...@gmail.com> wrote:
>>
>>> 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 th=
ing
>>> 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 wa=
y,
>>> and so I developed some templates to automate all the bitshifting. Usin=
g
>>> this I was able to create a much nicer interface to memory mapped devic=
es
>>> than the typical set of #defines provided by chip vendors (gist with an
>>> example: https://gist.github.com/LordPython/e9f58255ae8bee7102dc603d2
>>> 9bb919f).
>>>
>>> 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 annoy=
ing
>>>
>>> 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 layo=
ut
>>> 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 i=
s in
>>> parsing binary messages when there are fields that are smaller than a b=
yte
>>> packed together - again here the exact layout is crucial to correctness=
,
>>> and portability is potentially a much greater concern than when develop=
ing
>>> 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 fiel=
ds
>>> very tightly into a 64 bit object so I could use atomic operations inst=
ead
>>> of needing a mutex. In this case, bitfields made sense because I did no=
t
>>> care at all how the bitfield was arranged, just that it was only 64 bit=
s 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 ea=
ch
>>> field, as well as a total size for the bitfield as a whole, something t=
hat
>>> 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++ me=
mory
>>> model for similar reasons that packing structs hasn't become standardiz=
ed?
>>>
>>> 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 w=
ith
>>> 2 more instructions for this example because of the way volatile works)=
..
>>> Though I'm sure many people here feel the same way :P
>>>
>>> --
>>> 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/is
>>> ocpp.org/d/msgid/std-proposals/289ee4d8-01ce-4628-b788-
>>> 0e128c8be2d9%40isocpp.org
>>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/289ee4d8-=
01ce-4628-b788-0e128c8be2d9%40isocpp.org?utm_medium=3Demail&utm_source=3Dfo=
oter>
>>> .
>>>
>>
> 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 becaus=
e
> 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.
>
> --
> 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-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@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
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/de5bfa10-e0=
bf-4669-b6ef-bf008d6676a4%40isocpp.org?utm_medium=3Demail&utm_source=3Dfoot=
er>
> .
>
--=20
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 e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CAFdMc-39CpOWdJzN1dc%2B7v_J--XJ%3DD5bH%2BDCPBR2J=
BN3yoDgCA%40mail.gmail.com.
--001a114e1d82a5eb2b0552c75ca4
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"auto">(Sorry top posting since not following a particular answe=
r)<div dir=3D"auto">This might also be relevant: our paper and the discussi=
on.</div><div dir=3D"auto"><br></div><div dir=3D"auto"><a href=3D"https://w=
g21.cmeerw.net/ewg/issue122">https://wg21.cmeerw.net/ewg/issue122</a><br></=
div><div dir=3D"auto"><br></div></div><div class=3D"gmail_extra"><br><div c=
lass=3D"gmail_quote">El 25 jun. 2017 2:47 a. m., "Joseph Martin" =
<<a href=3D"mailto:pythoner6@gmail.com">pythoner6@gmail.com</a>> escr=
ibi=C3=B3:<br type=3D"attribution"><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=
=3D"ltr">On Sunday, June 25, 2017 at 1:07:54 AM UTC-4, John McFarlane wrote=
:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;bord=
er-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>There's =
a related paper from Klemens Morgenstern which was discussed recently in St=
udy Group 14 including in the forum [1]. Kvasir provides bitfields function=
ality specialized for embedded systems [2].<br><br></div>John<br><div><br>[=
1] <a href=3D"https://groups.google.com/a/isocpp.org/d/msg/sg14/E_EKDsAgFq0=
/oaQP9gKkCQAJ" rel=3D"nofollow" target=3D"_blank">https://groups.google.com=
/a/is<wbr>ocpp.org/d/msg/sg14/E_EKDsAgFq<wbr>0/oaQP9gKkCQAJ</a><br>[2] <a h=
ref=3D"https://github.com/kvasir-io/Kvasir" rel=3D"nofollow" target=3D"_bla=
nk">https://github.com/kvasir-io/K<wbr>vasir</a><br></div></div><br><div cl=
ass=3D"gmail_quote"><div dir=3D"ltr">On Sat, Jun 24, 2017 at 8:41 PM <<a=
rel=3D"nofollow">pyth...@gmail.com</a>> wrote:<br></div><blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pa=
dding-left:1ex"><div dir=3D"ltr">Hello everyone,<div><br></div><div>I'v=
e always been interested in embedded development and have gravitated toward=
s 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 usua=
lly involves doing a fair amount of bitshifting, and this can get rather te=
dious and error prone. I knew that there should be a better way, and so I d=
eveloped some templates to automate all the bitshifting. Using this I was a=
ble to create a much nicer interface to memory mapped devices than the typi=
cal set of #defines provided by chip vendors (gist with an example: <a href=
=3D"https://gist.github.com/LordPython/e9f58255ae8bee7102dc603d29bb919f" re=
l=3D"nofollow" target=3D"_blank">https://gist.github.com/LordPy<wbr>thon/e9=
f58255ae8bee7102dc603d2<wbr>9bb919f</a>).</div><div><br></div><div>Afterwar=
ds, I realized that I might be able to make this a lot simpler by using bit=
fields. And so I came up with this alternative prototype:=C2=A0<a href=3D"h=
ttps://gist.github.com/LordPython/0e9428c4d425a109d5a926ad1a7017c6" rel=3D"=
nofollow" target=3D"_blank">https://gist.github<wbr>.com/LordPython/0e9428c=
4d425a1<wbr>09d5a926ad1a7017c6</a>. However, I have a few concerns with the=
bitfield approach:</div><div><ol><li>They're not really portable as (a=
t least as far as I know) the layout of bitfields is implementation defined=
..</li><li>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</li=
></ol></div><div>It seems to me that almost all the times I'd want to u=
se bitfields are for things like this memory mapped IO where I care about t=
he 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 cr=
ucial to correctness, and portability is potentially a much greater concern=
than when developing software for a specific embedded system.</div><div><b=
r></div><div>In the past, I have had exactly one case I remember where I=
9;ve used bitfields, and that was when I wanted to pack a bunch of differen=
t 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 d=
id not care at all how the bitfield was arranged, just that it was only 64 =
bits in size.</div><div><br></div><div>So, I got to thinking that it would =
be really nice if bitfields were extended so that you could specify an expl=
icit offset and length for each field, as well as a total size for the bitf=
ield as a whole, something that works similar to the way Ada's record r=
epresentation clauses do (<a href=3D"http://www.ada-auth.org/standards/rm12=
_w_tc1/html/RM-13-5-1.html#S0313" rel=3D"nofollow" target=3D"_blank">http:/=
/www.ada-auth.org/stand<wbr>ards/rm12_w_tc1/html/RM-13-5-<wbr>1.html#S0313<=
/a>).</div><div><br></div><div>Does anyone else think that this might be a =
worthwhile extension of the language? Or does an extension like this not re=
ally fit with the C++ memory model for similar reasons that packing structs=
hasn't become standardized?</div><div><br></div><div>Also out of curio=
sity, has anyone else seen other good uses for bitfields in their current s=
ate?</div><div><br></div><div>- Joseph Martin</div><div><br></div><div>PS: =
The fact that my first example using templates compiles down to almost exac=
tly 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 instructi=
ons for this example because of the way volatile works). Though I'm sur=
e many people here feel the same way :P</div></div>
<p></p>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a rel=3D"nofollow">std-proposal...@isocpp.org</a>.<br>
To post to this group, send email to <a rel=3D"nofollow">std-pr...@isocpp.o=
rg</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/289ee4d8-01ce-4628-b788-0e128c8be2d9%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" rel=3D"nofollow" t=
arget=3D"_blank">https://groups.google.com/a/is<wbr>ocpp.org/d/msgid/std-pr=
oposals<wbr>/289ee4d8-01ce-4628-b788-<wbr>0e128c8be2d9%40isocpp.org</a>.<br=
></blockquote></div></blockquote><div><br></div><div>Ah yes, that's ver=
y 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 offs=
et/start and end) instead of just the length because I find it less error p=
rone when dealing with the specifications which are often bit 0 is this, bi=
t 1 is that, bits 2-7 are that, etc.</div></div>
<p></p>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/de5bfa10-e0bf-4669-b6ef-bf008d6676a4%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/de5b=
fa10-e0bf-4669-<wbr>b6ef-bf008d6676a4%40isocpp.org</a><wbr>.<br>
</blockquote></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAFdMc-39CpOWdJzN1dc%2B7v_J--XJ%3DD5b=
H%2BDCPBR2JBN3yoDgCA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFdMc-39Cp=
OWdJzN1dc%2B7v_J--XJ%3DD5bH%2BDCPBR2JBN3yoDgCA%40mail.gmail.com</a>.<br />
--001a114e1d82a5eb2b0552c75ca4--
.