220 32873 article Path: news.gmane.org!.POSTED!not-for-mail From: Joseph Martin Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Extending Bitfields Date: Sat, 24 Jun 2017 22:46:58 -0700 (PDT) Lines: 260 Approved: news@gmane.org Message-ID: References: <289ee4d8-01ce-4628-b788-0e128c8be2d9@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_1457_573946451.1498369618518" X-Trace: blaine.gmane.org 1498369622 12702 195.159.176.226 (25 Jun 2017 05:47:02 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 25 Jun 2017 05:47:02 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBC323BUL2IMRBU44XXFAKGQENFXGJBA@isocpp.org Sun Jun 25 07:46:57 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ua0-f198.google.com ([209.85.217.198]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dP0Nr-0002st-BE for gclcip-std-proposals@m.gmane.org; Sun, 25 Jun 2017 07:46:55 +0200 Original-Received: by mail-ua0-f198.google.com with SMTP id l38sf25916444uaf.1 for ; Sat, 24 Jun 2017 22:47:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:message-id:in-reply-to:references:subject:mime-version :x-original-sender:reply-to:precedence:mailing-list:list-id :list-post:list-help:list-archive:list-subscribe:list-unsubscribe; bh=cHDEgvLYWTcoCHdGw19MjseDVjcn/sfM9jdqo2mVMSE=; b=sbm6AYzBoPlBJODQSeBG+ZOnMWG5RHx7YmyzHlOAeRSpI/7LFVvya/7sy9TtunZEiB Exy1z2EvWu3U8ZX8YoWuXT7JhjAiy8+Be5bO5sX8NdmYDI0DZb6/XozbGGZMgnl4NOdn wKR12Q4qPVu6QrDg7rzDQu5hqYu9ljPKIM1K1HcFUEJ/MaWj9hye8iERVDHcZ98XS6a1 xaRBpK6IQxUl+l2IOu6gi8K3rB6lkyQeEtC0XcdFfxSX/oO/IfvihpBLVmvgOBtw2oTK N7DEwrKOSbSfwyROde/BT7+NIEC8fhX50zCu3E9Tu5MToFhJRyJJiC/041IkwAy3JVVE 8CsA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:message-id:in-reply-to:references:subject:mime-version :x-original-sender:reply-to:precedence:mailing-list:list-id :list-post:list-help:list-archive:list-subscribe:list-unsubscribe; bh=cHDEgvLYWTcoCHdGw19MjseDVjcn/sfM9jdqo2mVMSE=; b=AIkYHd1Tj4z47MKzgcKJb5eWya9gjROvE3KCF4h2fp0yTcG3vbfQffa/tfx4sBFy0q VIWM3I4I2C77WxYQh+DPW/NVypFBKDFF/KqU2eGAj5e0YAoVlE9ZOaR2YaV0f/JA8qR/ x5KtTL2eK+tyiwMRwC1I2Vfku6/kgVCaGGCY3FhTNj00DNaFpRivJqtcHD/VQag7TV/8 LRQos1fw5TAttpHWW0BZ/OJK6x/B4VtURL1AGO7AxGxAmZnR2Dp6WokPfYP7eVABzD9L kr/v/bBmGtDYaRliImNV6dFX8HTzegZxyO9iZHeXwBGjcBAXxvf5HS4ybRSMXms1bKgV 1mCw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:message-id:in-reply-to:references :subject:mime-version:x-original-sender:reply-to:precedence :mailing-list:list-id:x-spam-checked-in-group:list-post:list-help :list-archive:list-subscribe:list-unsubscribe; bh=cHDEgvLYWTcoCHdGw19MjseDVjcn/sfM9jdqo2mVMSE=; b=FwEL23VYCPS2DjheVXZ1/j2IQA1UL8eQ0QtGkuT8nFTV1HZAICcJzCnsIZEGY1VRye WXEJNTTuK5p8yYZAN5JGc24uItk2vtWKkmGcSGp2nExRtBL6IBBX1kdnVzvztEfb3par dDxGL975N/wRsvWTl2T1bOBcCMnlkyybpM0UE7S2m1+yzjJUTOqN6DHKIW47fWzjt0nt 0H/xUXFf11VDxyciJb3nLxWhS3WuZENJWM8pouAK+8UoW6iN0vuzsLuiMe4TTE8EQLqf uu7julyNx/ViHnrM1H5VMNFghVulBllUaMkpVi9GqUDRJdKZQOpmRfL3z0x5a+2kIQvF ygzQ== X-Gm-Message-State: AKS2vOxUy9mQ3dJjWQRScRlHDX52Z7GmmiARA+JNm+3eay78fZaq8qcS cuvM63U4OZV+gVnT X-Received: by 10.176.23.94 with SMTP id k30mr8166828uaf.34.1498369620139; Sat, 24 Jun 2017 22:47:00 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.157.12.226 with SMTP id o31ls10995880otd.2.gmail; Sat, 24 Jun 2017 22:46:59 -0700 (PDT) X-Received: by 10.157.32.55 with SMTP id n52mr278850ota.10.1498369619060; Sat, 24 Jun 2017 22:46:59 -0700 (PDT) In-Reply-To: X-Original-Sender: pythoner6@gmail.com Precedence: list Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org List-ID: X-Google-Group-Id: 399137483710 List-Post: , List-Help: , List-Archive: List-Subscribe: , List-Unsubscribe: , Xref: news.gmane.org gmane.comp.lang.c++.isocpp.proposals:32873 Archived-At: ------=_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 > 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 . >> 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 >> >> . >> > 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
On Sunday, June 25, 2017 at 1:07:54 AM UTC-4, John McFarla= ne wrote:
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].

John<= br>

<= div dir=3D"ltr">On Sat, Jun 24, 2017 at 8:41 PM <pyth...@gmail.com> wr= ote:
Hello everyon= e,

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: https= ://gist.github.com/LordPython/e9f58255ae8bee7102dc603d29bb91= 9f).

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=A0https://gist.github.com/LordPython/0e9428c4d425a109d5a926ad1a701= 7c6. However, I have a few concerns with the bitfield approach:
  1. They're not really portable as (at least as far as I kn= ow) the layout of bitfields is implementation defined.
  2. 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
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.

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.

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 (http:/= /www.ada-auth.org/standards/rm12_w_tc1/html/RM-13-5-1.html#S0313<= /a>).




--
You received this message because you are subscribed to the Google Groups &= quot;ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail 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.

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>

--
You received this message because you are subscribed to the Google Groups &= quot;ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to std-proposa= ls+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-- ------=_Part_1457_573946451.1498369618518-- .