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=-2.9 required=5.0 tests=BAYES_00,MAILING_LIST_MULTI autolearn=unavailable autolearn_force=no version=3.4.4 X-Google-Thread: 103376,36b302576d78847a X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news2.google.com!news4.google.com!border1.nntp.dca.giganews.com!nntp.giganews.com!aotearoa.belnet.be!news.belnet.be!nerim.net!proxad.net!cleanfeed2-b.proxad.net!nnrp10-1.free.fr!not-for-mail Return-Path: In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.2) X-Priority: 3 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit From: Marius Amado-Alves Subject: Re: How do you bitwise operations in Ada '83 and '95 Date: Fri, 21 Jul 2006 06:38:12 +0100 To: comp.lang.ada@ada-france.org X-Mailer: Apple Mail (2.752.2) X-Antivirus-Scanner: Clean mail though you should still use an Antivirus X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - zaphen.serversonline.net X-AntiAbuse: Original Domain - ada-france.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - amado-alves.info X-Source: X-Source-Args: X-Source-Dir: X-Virus-Scanned: amavisd-new at ada-france.org X-BeenThere: comp.lang.ada@ada-france.org X-Mailman-Version: 2.1.8rc1 Precedence: list List-Id: "Gateway to the comp.lang.ada Usenet newsgroup" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Newsgroups: comp.lang.ada Message-ID: X-Leafnode-NNTP-Posting-Host: 88.191.17.134 Organization: Guest of ProXad - France NNTP-Posting-Date: 21 Jul 2006 07:40:26 MEST NNTP-Posting-Host: 88.191.14.223 X-Trace: 1153460426 nnrp10-1.free.fr 18902 88.191.14.223:53437 X-Complaints-To: abuse@proxad.net Xref: g2news2.google.com comp.lang.ada:5849 Date: 2006-07-21T07:40:26+02:00 >> Implemented as a modular type the predefined relation >> functions are gratis--and surely correct. > > Only if you've carefully laid out the order of the bits so that > will work. Sure, but that's really easy, no? Year, Month, Day, Seconds... > Which is much more likely to ruin the alignment of the bit-field > components > (an important part of maximum performance). For records. For a 64-bit unit it does not matter for the "<" functions where the fields are. >> And the expressions are not >> complex. Once you get the masks and magnitudes right, it's simply >> >> Part := (Whole and Mask) / Magnitude. > > But that's for each component. Surely you do other operations (like > difference in seconds) where the expressions are far more complex? Actually, in this case, no. I leave it to Ada.Calendar. Convert, compute, convert. This limitation is documented. > All-in-all, I prefer the record representation. For Calendar_64 I specifically wanted a 64-bit string, it was a requirement. If I was to implement Ada.Calendar I think I would use a record too, because it is a private type by definition, so I would have to write the "<" functions anyway. > Janus/Ada Calendar.Time implementation is a 64-bit record type Just curious: is it aligned properly i.e. if you uncheckedly convert to a 64-bit modular will the modular "<" functions work properly i.e. represent the relations between the dates properly? Of course a Calendar_64 for a specific compiler/platform could take advantage of the respective Ada.Calendar representation.