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,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!local02.nntp.dca.giganews.com!nntp.megapath.net!news.megapath.net.POSTED!not-for-mail NNTP-Posting-Date: Fri, 21 Jul 2006 17:08:24 -0500 From: "Randy Brukardt" Newsgroups: comp.lang.ada References: Subject: Re: How do you bitwise operations in Ada '83 and '95 Date: Fri, 21 Jul 2006 17:09:30 -0500 X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1807 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807 Message-ID: NNTP-Posting-Host: 64.32.209.38 X-Trace: sv3-e7N5pt2a+wOcDCeYv6YgSWBbKwrcacJrxIy3sOsudfzR7PVqfp45zQLo4z8lmz6e90bKS4KAhQG8OY4!nNcKBlA/BRiPO+JqDyKeowBiPiH//KKbg9tv5q0/svriiBokGvclYK9P1hi0tDaDAYAfLdFCTC0x!UzE04exzUyO0MA== X-Complaints-To: abuse@megapath.net X-DMCA-Complaints-To: abuse@megapath.net X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly X-Postfilter: 1.3.32 Xref: g2news2.google.com comp.lang.ada:5870 Date: 2006-07-21T17:09:30-05:00 List-Id: "Marius Amado-Alves" wrote in message news:mailman.43.1153460313.30988.comp.lang.ada@ada-france.org... ... > > 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. That is only true on a 64-bit machine. On more typical 32-bit machines, you are doing double precision math to extract a few bits from the middle. That's going to be more expensive. > >> 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. Sounds nearly useless. Especially as Ada.Calendar.Time is a 64-bit type on most compilers (but I realize you can't depend on that). Even so, I'd expect that your equivelent of Time_Of would use a pretty complex expression. > > All-in-all, I prefer the record representation. > > For Calendar_64 I specifically wanted a 64-bit string, it was a > requirement. Yes, but that has nothing to do with whether it is represented as a record or not. Just put a size clause on your record: for My_Time'Size use 64; If you need an untyped blob for some reason, its easy enough to use an Unchecked_Conversion. But it's often easy to avoid the need to have it untyped in the first place -- we did that in many places in the Win32 calls that underlie Claw. > 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? I think so, but it is a moot point: Janus/Ada doesn't (currently) support any 64 bit integer or modular types. So you'd have to convert to a Storage_Array or Stream_Array or similar. > Of course a Calendar_64 for a specific compiler/platform could take > advantage of the respective Ada.Calendar representation. Yes, of course. Randy.