220 32875 article Path: news.gmane.org!.POSTED!not-for-mail From: "dgutson ." Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Extending Bitfields Date: Sun, 25 Jun 2017 08:44:49 -0300 Lines: 294 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="001a114e1d82a5eb2b0552c75ca4" X-Trace: blaine.gmane.org 1498391093 10497 195.159.176.226 (25 Jun 2017 11:44:53 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 25 Jun 2017 11:44:53 +0000 (UTC) To: std-proposals Original-X-From: std-proposals+bncBDE3NBMV6UFBBMWEX3FAKGQETMDQGBY@isocpp.org Sun Jun 25 13:44:47 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ot0-f197.google.com ([74.125.82.197]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dP5yA-0002LC-SR for gclcip-std-proposals@m.gmane.org; Sun, 25 Jun 2017 13:44:47 +0200 Original-Received: by mail-ot0-f197.google.com with SMTP id f20sf64639841otd.9 for ; Sun, 25 Jun 2017 04:44:52 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1498391091; cv=pass; d=google.com; s=arc-20160816; b=baxoQThZEC1Ryk+STVnO0Y7dEx4K6K09Vl9bVZRAGnX65gfZ+p8DLXSD2wVvB/7cl/ Dt5vzwEypHvtUulx+ZRqkNfUUVfvA6k5LR1ghoMulejYyak4mmrqO5el3aXWP6h2o9Je nwrpW4d0JwzVL1bkkDi3QWMKpR+B1h4/r0sldfAnJaHaktnjKXllI83suDWw6CX449KE e43wfiAQv7Z9evcyk2mdcdfyRODhdoZOWJHXMReb2V6bk+zZhXBly2waqMNuzpvxSqLk kAc6X1TrZxabci1d/xmSNvehK11ynfkX7zpcx1BYIPSxCvVWJ1suqO9aqHHo+9Sj7HEu NuuA== 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:references:in-reply-to:mime-version:arc-authentication-results :arc-message-signature:dkim-signature:arc-authentication-results; bh=3CslCbVWTxhWxIxNCsaHbfi6zWSg70DnxbanRI1pGiQ=; b=KSvjXkistyL+AKV0CucybjIImatOFKfDsHVs0J2SNGbGgqjr5xyKYCAcTiqezKBOFP KzKcyreTuFOPRErJm3IYqTSQhpQdaRctebL2G3tT7+mFZswA3pi7pxgNCdL7whd9eWw3 YJYGgAWeLOQG2Yrf+w0fYhPSPF9cGVGWrqpwl0ce5hnrnN7ac/svX7TCqaZBSyJ1d2pc nt4qS07n6E1jGlgrSLILPXcfr06kLExTXlleq1M4A0Ym8SU3atyyRV1yXL1leMGQRmaF 5bSODwj/ge8i9jYq7dhnI4lMvLWZRw/LIS8ulklVYqfEQTM/URKcCFOcIsMHyUuCxiEN S+1w== ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@gmail.com header.b=VA4Pk7Kk; spf=pass (google.com: domain of danielgutson@gmail.com designates 2607:f8b0:4002:c09::22b as permitted sender) smtp.mailfrom=danielgutson@gmail.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=gmail.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references: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=3CslCbVWTxhWxIxNCsaHbfi6zWSg70DnxbanRI1pGiQ=; b=qmaMWG3EvkCkt1qJ5Y4mWv1295sDe0KicCxLQlH4DhOyk96D/2uNOPoxcKkTWCmLSB FGL5B55TaJwHckRcXd1fKJKPeCVu/YLV+la58OcZsJUHZRm6dne2tcUMUjkcPF3ZXM/5 Qv42s4OXAKU6ydgjfFGHiTIhmoBSoNg0mNXwMzpHj0ULj2fXojPDDTA/5gU1UqEailN3 nMhkKLpNNSVzxv3JCzf8DlwfGdIQ2zbcnODEs6vm9TvDAOL0VQ1AhgY/icWPzNQ6AHmO uD9zm5yf+YdUqQ/UXL3M2Q+gFPp7rzUDohMNXtow/Ol1KvjIwMxlGv6eqomnLnAfMLEA 9jXQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references: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=3CslCbVWTxhWxIxNCsaHbfi6zWSg70DnxbanRI1pGiQ=; b=KU5MEQWITQAegTxCeUszIuGyDoR+GrNS+vf3N6/ZHFU5L2PlT5v4cVIp7+9GB2bJ9L TE55iiPnRrGoCE1OpOUioG6MScOidsCFWm8Q5xxibHAFfiVXwfymH9r0GV5UWvAATlvU mqPZ2A65ae4gnMAyVRapZFEWDHf2I+IIgpX+vyO1+4zmTvUIAjplyzu05m+RuOFHvQqI 3n7p5lFgs9RABpzBPha/RYVM5hhk2vTKXIoHyuuFtz31ACJOcxEd2IxcvfNeOrUifQYj v6R+QFH7NYVrpvoE5HiP5BfbdMBCALdKcMb7uqtRXXfWjmrABylacbItSRsCyYD1T09q VG9Q== X-Gm-Message-State: AKS2vOxxG3DTAMq0Qfe0rLu53BvmskmqzBN1LGQ2MV7wsCDJ7LWZcHDS bvrewNpgFefbGDOW X-Received: by 10.157.15.218 with SMTP id m26mr9627200otd.63.1498391091548; Sun, 25 Jun 2017 04:44:51 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.157.61.228 with SMTP id l91ls1900949otc.21.gmail; Sun, 25 Jun 2017 04:44:50 -0700 (PDT) X-Received: by 10.129.51.74 with SMTP id z71mr11735306ywz.260.1498391090424; Sun, 25 Jun 2017 04:44:50 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1498391090; cv=none; d=google.com; s=arc-20160816; b=OvPQ16+G1Xg5PN7qzgNcbOnn/n/7s6T5wlvgVlnXUxsOEZsY/2wKDCQn3ZMAD20Y2V yB9rMW6yAaKiZbOBCItL5fSTUFCSR8aMA2unkPZREDbagircFpllD0UeODl05Y8rYExv RwHzuRootrwiYBaOXpJoy6dt/GsrSq7PquZ9dOLhc2KX0t//ipigWqAgDVJDb/pxpmvP lbPHteVvJN9iHTXLVSm2UTmYMM/yU9qx246LtBXyQ81u2kFYX9nUQoWG6UpzFeVQM/7O +UoN0rzyLNiYBeTEZB9dVeVsgMqDHLSWX9HtY7ngWrutpDYE9qnNtlghX3ThiGuGkE6b Hy4Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=to:subject:message-id:date:from:references:in-reply-to:mime-version :dkim-signature:arc-authentication-results; bh=uu5ODhyH/4f0DfwO0unyBfHVeNd51QO82RdbK/lEpMc=; b=TWmIVdm+4NY7Ud3RT9vXPwNumsmMOfqTQX+nJAvYr2ZP8dIEea7fHjxNHmTxOk8Ctq iPQZ0dIlHB/47Kc6po8H2xpfN0Kx0G6FP3MRpYP1HK8oKsCyL0yoPwY/7TovpCFeNtxy i8HgQDS69AfL0tNmxNVxgiMEdLxxPTlTU4aprcYFJVdtAwXJOPM1Y7tfCffzyLQGQGzM CTfFa1SgFQJxpESZGAUJE3n8+GSCbqikB+0d6GK/Det8KZcw2U9oSI475hUPY9c86Y28 Z81UA54Bkm9VY28lPT/3D71LenQpR337l10VWxCh9C+lt6Hqzu3DQS3pVo8+vovss2mv H1YQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.b=VA4Pk7Kk; spf=pass (google.com: domain of danielgutson@gmail.com designates 2607:f8b0:4002:c09::22b as permitted sender) smtp.mailfrom=danielgutson@gmail.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=gmail.com Original-Received: from mail-yb0-x22b.google.com (mail-yb0-x22b.google.com. [2607:f8b0:4002:c09::22b]) by mx.google.com with ESMTPS id w10si1231919ybw.112.2017.06.25.04.44.50 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 25 Jun 2017 04:44:50 -0700 (PDT) Received-SPF: pass (google.com: domain of danielgutson@gmail.com designates 2607:f8b0:4002:c09::22b as permitted sender) client-ip=2607:f8b0:4002:c09::22b; Original-Received: by mail-yb0-x22b.google.com with SMTP id 84so22627294ybe.0 for ; Sun, 25 Jun 2017 04:44:50 -0700 (PDT) X-Received: by 10.37.123.5 with SMTP id w5mr11638253ybc.58.1498391089898; Sun, 25 Jun 2017 04:44:49 -0700 (PDT) Original-Received: by 10.129.115.195 with HTTP; Sun, 25 Jun 2017 04:44:49 -0700 (PDT) Original-Received: by 10.129.115.195 with HTTP; Sun, 25 Jun 2017 04:44:49 -0700 (PDT) In-Reply-To: X-Original-Sender: danielgutson@gmail.com X-Original-Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.b=VA4Pk7Kk; spf=pass (google.com: domain of danielgutson@gmail.com designates 2607:f8b0:4002:c09::22b as permitted sender) smtp.mailfrom=danielgutson@gmail.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=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:32875 Archived-At: --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" 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 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 >>> >>> . >>> >> > 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 > > . > --=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
(Sorry top posting since not following a particular answe= r)
This might also be relevant: our paper and the discussi= on.


El 25 jun. 2017 2:47 a. m., "Joseph Martin" = <pythoner6@gmail.com> escr= ibi=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 St= udy Group 14 including in the forum [1]. Kvasir provides bitfields function= ality specialized for embedded systems [2].

John

On Sat, Jun 24, 2017 at 8:41 PM <pyth...@gmail.com> wrote:
Hello everyone,

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: https://gist.github.com/LordPython/e9= f58255ae8bee7102dc603d29bb919f).

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=A0https://gist.github.com/LordPython/0e9428c= 4d425a109d5a926ad1a7017c6. However, I have a few concerns with the= bitfield approach:
  1. They're not really portable as (a= t 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 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.
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.

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 (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.o= rg.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-pr= oposals/289ee4d8-01ce-4628-b788-0e128c8be2d9%40isocpp.org.

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.

--
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/de5b= fa10-e0bf-4669-b6ef-bf008d6676a4%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 https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFdMc-39Cp= OWdJzN1dc%2B7v_J--XJ%3DD5bH%2BDCPBR2JBN3yoDgCA%40mail.gmail.com.
--001a114e1d82a5eb2b0552c75ca4-- .