220 32872 article Path: news.gmane.org!.POSTED!not-for-mail From: John McFarlane Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Extending Bitfields Date: Sun, 25 Jun 2017 05:07:41 +0000 Lines: 195 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/alternative; boundary="001a113eb1c401e9510552c1d179" X-Trace: blaine.gmane.org 1498367274 14365 195.159.176.226 (25 Jun 2017 05:07:54 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 25 Jun 2017 05:07:54 +0000 (UTC) To: "ISO C++ Standard - Future Proposals" Original-X-From: std-proposals+bncBDS7B7WQUYOBBKMKXXFAKGQEISJDC6Q@isocpp.org Sun Jun 25 07:07:49 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-lf0-f71.google.com ([209.85.215.71]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dOzm1-0003Ps-9Z for gclcip-std-proposals@m.gmane.org; Sun, 25 Jun 2017 07:07:49 +0200 Original-Received: by mail-lf0-f71.google.com with SMTP id c199sf4576270lfg.8 for ; Sat, 24 Jun 2017 22:07:54 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1498367274; cv=pass; d=google.com; s=arc-20160816; b=wbDi/bR7zsP4Glh3e7SpLqrvmZ8rmBcQS8Xoo40wWCDiTBeew/2B+U/zou1lXRPJQ8 F8qIYkbWMmHeGetalhwmfgsbmNfj5VsyR1XsP8URmj22AdzLiXSNVzecg33ttndoC7pN 6NdF/uhnm1BhywvUiNrtdeaeHDTWIK2re4/aB34bMkUQoAFf2KbxsM0XjvkXfTJZtLqn gCT7v/s/a3uIoH3IWoW5rjqCFgn+gbSmDjWUn/d+zAeINvbhhumR/fwiEW7ID/WsilNO Dh9LSkemN7ECYXvaQDMVL6EOJkROQYbTnbsALbK/7xSwRj0vxJzkCAtknqg8UeBZDWCF UNhg== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to:to:subject:message-id:date :from:in-reply-to:references:mime-version:arc-authentication-results :arc-message-signature:dkim-signature:arc-authentication-results; bh=PSvXELD2u2DkmSq3QPWGaFcpKL1tG1TdO0MLAc9DKho=; b=NK+B55pBp07YirQKd6TL393p/8nNxkXIohlBlUfkSwIRjA11wtUmzWmEWhp/mciSKw gwkn2/gR0rzCsDMfH7oseZfIhGtTt+RLTej1fCdlak8L65THPF8XtBmqXdBsD9bUW+Jd P3c5xKGLcoa1p8zhA8khirUCGXaTREBH2daqB4H6Qh638WdSR6lGzuL9/WLft+z991T4 qiZZpQQk2SDKMj9+HL5LDg65FqyH8n0J9dg2iwse234fa2OAVnbjjpeZrGFEzXbFsnai LRTEeUtSHD3orf6vNVr5LwK1lLzHsOhL4CXBDAGBvtHXcabtwlTOFDibVhoGlyh1h2Gn ITNA== ARC-Authentication-Results: i=2; mx.google.com; spf=pass (google.com: domain of mcfarlane.john@gmail.com designates 209.85.128.181 as permitted sender) smtp.mailfrom=mcfarlane.john@gmail.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :x-original-sender:x-original-authentication-results:reply-to :precedence:mailing-list:list-id:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=PSvXELD2u2DkmSq3QPWGaFcpKL1tG1TdO0MLAc9DKho=; b=bsdbCbuoWSdDFyUJ2pRzxYOT9MeLkJRQLCkBFKwwxigocd4M6N2dy52oXchZvSNmtS GQdHg58vwD6qGgGgcLX+ewDHRGICQiDO4iT0k1BxCrxU34ZhNnXSpR2WGqm6JVdSO2Hu vr+XMHA0L8YxhKLrFpCDUjj8gnOwEn97iCmz2NkjbTI21Sc/+2RY34+8psF5VL/zT1NX 79b05Pd8NoTrrUNCvF88mFiVuTRGsfXuzVvFN/2tjcj6xjM7n49l/rht8BpQYiswJ2tF EZPlTqRBlhaj7J5pqVAj7GBMvsiwHcaV7nw/WccHhfnJ/auk4eJICmYodYhEf9AqYlZ/ qN/A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:x-original-sender :x-original-authentication-results:reply-to:precedence:mailing-list :list-id:x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=PSvXELD2u2DkmSq3QPWGaFcpKL1tG1TdO0MLAc9DKho=; b=kGQHNn2aWHnDZa0l9is42iP+Z016XNNmzdhykZO3LCdRgjaGEOOCqNGE17yYTwcOP6 R4Rt+TEMwrwQGQ5dnWPSFdQ1TFq6qx3aiRIdr0yExoCziQVi1biIa4lrY+NJIDrc0ctX jeuZ34W364Gs8qwMR8jpLQ7aYGPCTat2stHmF0fLtrmsDShFkndERf7SZdVF0r+SVhDT 9JtUc+xMDCsymT+b/aaILAlGGAubtvjDV2azR4vRt41lgHHVs/S/wy4ab3DGjCyXtsMm nsnVRXmcSvJkQ+dJUY6bakcjHROosaohGdO3JVwfdgGGILsPprfc9J/Sffkn3QJr8nmh oAHg== X-Gm-Message-State: AKS2vOwvF9A9TMPz+Q5vYq2peiC2F8DwfG220VNrkjuPDbY/2Zwu2vPy iU7sEbkFqmgbiQ== X-Received: by 10.46.8.66 with SMTP id g2mr2562221ljd.2.1498367274486; Sat, 24 Jun 2017 22:07:54 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.28.54.34 with SMTP id d34ls1202023wma.14.canary-gmail; Sat, 24 Jun 2017 22:07:52 -0700 (PDT) X-Received: by 10.28.8.72 with SMTP id 69mr9468971wmi.102.1498367272892; Sat, 24 Jun 2017 22:07:52 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1498367272; cv=none; d=google.com; s=arc-20160816; b=HKBMN1FQMmcbInzCOtPavnSnkDVWBwOsR7kL4yM2F1lrIatqfZkCMEqH82MalNREKv W5dqm0RzKzXAbaH5+dugflqa3qVYgHdKrKWPgN2oJYCVJXoGFXDmtqJMioNOY7m0LgZy Mbobght1x0UWcV10hWSqReQ/JJkmbNU23q4gEq7fL0hhmJ+JC83vZnEec42tltFAT3SJ XfJh2tVMoKnnygzbXPvEtLxNAmR0i6sDMBzXURxf3NXAGGXG+2u/OiDTfaBoZiZrFgRL Q/yA+oowmxtjhbu5/M1MV7DLg1cP/ibGHOzGKEvRFwOGUkWbSKhC3iTnf5PFBePaD7fF WBsg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :arc-authentication-results; bh=vwYi/vZ7erAAUDuNRm8Dbp3aXtyPVeDiv5hs80yuwRg=; b=MZYw9UnbAaDpjHxhJToe07/gtQ0FSNlUCSdqbMdYSmefVT2Wskzvmv/TMQ6TwWAcwl 1RGXaN7E8l3DQ2AnJEt7GmfK8t+7rafwe/kDPELByCZBLzFD3rl4Ig+fSjDubtlTxZjn OCJEgeSIiCEdLSMGqASBC7ctgWPUfA0tPz5dJi//0nHkZorBe09gFwt7WvIr/6M2KdY9 lvooMp94ARmZeuyggzTzd+gXj0iGVoHn2Yp5kamiRj7oUUPN+nRXHB3IVIAJYIoEVo7N H6c1tdHgruC+VgksAPa7ZfOl4PlccmvyW3gffap9RD7iocIO+e/WQaRfGtqFo1Fo97PO ps+A== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of mcfarlane.john@gmail.com designates 209.85.128.181 as permitted sender) smtp.mailfrom=mcfarlane.john@gmail.com Original-Received: from mail-wr0-f181.google.com (mail-wr0-f181.google.com. [209.85.128.181]) by mx.google.com with ESMTPS id j198si8279157wmg.14.2017.06.24.22.07.52 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 24 Jun 2017 22:07:52 -0700 (PDT) Received-SPF: pass (google.com: domain of mcfarlane.john@gmail.com designates 209.85.128.181 as permitted sender) client-ip=209.85.128.181; Original-Received: by mail-wr0-f181.google.com with SMTP id c11so112355324wrc.3 for ; Sat, 24 Jun 2017 22:07:52 -0700 (PDT) X-Received: by 10.223.138.167 with SMTP id y36mr10622445wry.93.1498367272280; Sat, 24 Jun 2017 22:07:52 -0700 (PDT) In-Reply-To: <289ee4d8-01ce-4628-b788-0e128c8be2d9@isocpp.org> X-Original-Sender: john@mcfarlane.name X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of mcfarlane.john@gmail.com designates 209.85.128.181 as permitted sender) smtp.mailfrom=mcfarlane.john@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:32872 Archived-At: --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 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 > > . > -- 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
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

On Sat, Jun 24= , 2017 at 8:41 PM <pythoner6@gmai= l.com> wrote:
Hello everyone,

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: https://gist.g= ithub.com/LordPython/e9f58255ae8bee7102dc603d29bb919f).

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

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 (http://www.ada-auth.org/standard= s/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 f= or similar reasons that packing structs hasn't become standardized?

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

- Jose= ph Martin

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

--
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-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.

--
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 htt= ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CABPJVnTemri7jarr= F9HVQtRcstyj5E6CEex43X2S9RcM3sFLMw%40mail.gmail.com.
--001a113eb1c401e9510552c1d179-- .