220 32869 <289ee4d8-01ce-4628-b788-0e128c8be2d9@isocpp.org> article Path: news.gmane.org!.POSTED!not-for-mail From: pythoner6@gmail.com Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Extending Bitfields Date: Sat, 24 Jun 2017 20:41:20 -0700 (PDT) Lines: 145 Approved: news@gmane.org Message-ID: <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_1372_1791096360.1498362080162" X-Trace: blaine.gmane.org 1498362083 22310 195.159.176.226 (25 Jun 2017 03:41:23 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 25 Jun 2017 03:41:23 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBC323BUL2IMRBYHBXTFAKGQE4I6LW2A@isocpp.org Sun Jun 25 05:41:19 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-io0-f199.google.com ([209.85.223.199]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dOyQG-0005Ok-FC for gclcip-std-proposals@m.gmane.org; Sun, 25 Jun 2017 05:41:16 +0200 Original-Received: by mail-io0-f199.google.com with SMTP id j200sf69154832ioe.2 for ; Sat, 24 Jun 2017 20:41:21 -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:subject:mime-version:x-original-sender :reply-to:precedence:mailing-list:list-id:list-post:list-help :list-archive:list-subscribe:list-unsubscribe; bh=Xrf8NdMAeiQJ7wJ+5sF0Qzc/wMMBxJkF7g+1GHGXnjc=; b=yxkJkzcWT9JpuMnAQ670mG+ar4N2NMwwtbJGdBPJ6abORUsMdSxkgQISLojCU8jVv0 MRyf1apJUlKYUSQ4AJ4dkO+LhkeI2qXYhlSBI8d3IRbm4dU0jrsgY5ADnwbbUCJtTqrj diR2FpqLo/RQU0Uokx7CFRN/fNO8MACvTMhHmeobM9qpPruLBULNY1y/01dcnjrWW3Y9 rJENd3Goq/yq1njyZVYmOw0NcbViuGDpUsH2fkhDxNujBsH5Hk+zlSpSJtKIAvTGEwNG o3Q0pyu8jJmVx82bGqj2Q7KDN9MDsguhugoIlR7FnhjOFHi2htSof9ta7fco0HSJNej5 FLsA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:message-id:subject:mime-version:x-original-sender :reply-to:precedence:mailing-list:list-id:list-post:list-help :list-archive:list-subscribe:list-unsubscribe; bh=Xrf8NdMAeiQJ7wJ+5sF0Qzc/wMMBxJkF7g+1GHGXnjc=; b=eJCNEOdccUTSH5yAyCI9pbxfY/lgH+M4IpEx0hiV44ka89Lp6Tx7bHFEs5PWbH2Ywu 8oe7yAseKdtJBLwu3rh4zAc1AtoYrneTJcBlMMDivPtDHv1MX3eb9Jj7HOtddLydjVMN ag1CEsNbaDno4UHKKSRMpO4KyHlwNyFdSC5IXIoMu+rZy6gk7NJKqBbC5HE1ADruSNiq mpfLYRPdX1Y6+6luucmTUFtu4osejgoPcyXzkjtS6V8uXVkpA40q77mQX7E9HEoI10Ec znOOsjzS8qbrRypD77cw3douzBC4YrJCpbdK5yMUX6JhZsPD7W+O39IqXtVGfyDvRSw+ gHoQ== 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: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=Xrf8NdMAeiQJ7wJ+5sF0Qzc/wMMBxJkF7g+1GHGXnjc=; b=KpRc82kSA/LrY78CJzSHZ7EC6FCDtTibyfrv48ZbqGGSTdyoYTj4Nre7D/nPP40h78 WgNaCf0aexGqTIoCoHCCfAx3BUG2MlPis6bmL0yupypFqIB5S9RnMM20VyYaRW+xNM/0 mMyr4X780ucWk492U63tzvKtygr44QTfN0FZuzl/wYZ9vPuaN4k09n8qdiInwlJcgA2s qnGUT2DR2YaB546v35FPRuAm4y6DbB6sJCk+1oP1wdHiax08qUx5W6V50LFf4puuCxrh gpC0J1km5FdjdpQ5pyrWoPcKICWhPxW3Y+ym5fi7JG93Rfj4tw5l9ZA/CiytpV1NOtV7 C/Tg== X-Gm-Message-State: AKS2vOxYyR/aoa+jIiAQL5Tx6u2LuvIfTNtMulm8fXv0d5go91mV9MY9 hPcM1j4QaJMjcXnL X-Received: by 10.107.173.29 with SMTP id w29mr8186683ioe.84.1498362081341; Sat, 24 Jun 2017 20:41:21 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.157.48.211 with SMTP id r19ls6444794otg.14.gmail; Sat, 24 Jun 2017 20:41:20 -0700 (PDT) X-Received: by 10.157.48.161 with SMTP id s33mr370149otc.1.1498362080531; Sat, 24 Jun 2017 20:41:20 -0700 (PDT) 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:32869 Archived-At: ------=_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
Hello everyone,

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

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:
  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 h= ave their size specified, making sure that fields are at the right offset c= an be kind of annoying
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.

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.

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 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= ?

Also out of curiosity, has anyone else seen othe= r 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 sam= e 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-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/289ee4d8-01ce-4628-b788-0e128c8be2d9= %40isocpp.org.
------=_Part_1373_632297042.1498362080162-- ------=_Part_1372_1791096360.1498362080162-- .