From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,c5f68ab74d5099ee X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Received: by 10.68.212.232 with SMTP id nn8mr3180954pbc.1.1323902961470; Wed, 14 Dec 2011 14:49:21 -0800 (PST) MIME-Version: 1.0 Path: lh20ni23056pbb.0!nntp.google.com!news2.google.com!npeer03.iad.highwinds-media.com!news.highwinds-media.com!feed-me.highwinds-media.com!nx02.iad01.newshosting.com!newshosting.com!87.79.20.101.MISMATCH!newsreader4.netcologne.de!news.netcologne.de!feeder.erje.net!nuzba.szn.dk!news.jacob-sparre.dk!pnx.dk!jacob-sparre.dk!ada-dk.org!.POSTED!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: Interfaces.Shift_Left Date: Wed, 14 Dec 2011 16:49:15 -0600 Organization: Jacob Sparre Andersen Research & Innovation Message-ID: References: <18214312-82f5-45c4-b20d-cb530b500929@h3g2000yqa.googlegroups.com> <5f989095-5c1c-4b23-a538-d70f4718b4b1@l19g2000yqc.googlegroups.com> NNTP-Posting-Host: static-69-95-181-76.mad.choiceone.net X-Trace: munin.nbi.dk 1323902957 19682 69.95.181.76 (14 Dec 2011 22:49:17 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Wed, 14 Dec 2011 22:49:17 +0000 (UTC) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 X-RFC2646: Format=Flowed; Original X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Date: 2011-12-14T16:49:15-06:00 List-Id: "awdorrin" wrote in message news:a76daa61-49f7-4235-af65-11973a012f35@v29g2000yqv.googlegroups.com... >I understand what you are saying and I do agree in theory. > > The situation is that bit shifting is being used to retrieve data of > various bit lengths and positions from compound records. > > For instance, retrieving a 6-bit signed value from a 32-bit field. Right. This definitely should be done using record representation clauses if there is a choice. But of course if the code already exists, that might be too much. > For the purposes of obtaining those 6 bits - sign is irrelevant, but > that 6 bit value is then sent back to a calling process as an 'Int32' > so I need the sign then. Right. A record representation clause would do this correctly with no (visible) shifting, and it would be far less prone to errors. To take a quick example from my solitare solvers: Max_Score : constant := 1000; type Suits is (Diamonds, Hearts, Spades, Clubs); subtype Pip_Value is Natural range 1 .. 13; -- 1 = Ace, 13 = King. (I have names for these not shown here.) subtype Score_Value is Integer range -Max_Score..Max_Score; type Card is record Suit : Suits; Pip : Pip_Value; Score : Score_Value; end record; for Card use record Suit at 0 range 14..15; Pip at 0 range 10..13; Score at 0 range 0..9; end record; for Card'Size use 16; Great_Card : constant Card := (Suit => Spades, Pip => 1, Score => 800); Now, a reference to Great_Card.Score will give you a signed result, and the compiler will select the best set of shifts and masks for your target machine (not to mention combining them when possible). Much less complication, much easier to read, much less likely to make a mistake. > Given more time and funding, I would replace this logic with something > that makes more sense, but a quick Unchecked_Conversion saves > rewriting 15,000+ lines of code. :) I certainly understand, but personally I would guess that replacing the explicit shifting and masking with a record type would probably take me about the same time as writing all of the Unchecked_Conversion instances you would need. And there will be a lot less chance of error. YMMV, of course. BTW, if there are really 15000 lines that would get changed by this, there is a really bad lack of encapsulation with this code. The interfaces between Ada and other languages/hardware/OSes should always be made as narrow as possible, and always should go through a well-encapulated interface (so it is easy to change one side without distrubing the other). But I realize that you probably know this. Randy.