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=-0.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Thread: 103376,43ad9ab56ebde91c X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Received: by 10.68.191.41 with SMTP id gv9mr10014091pbc.5.1323714787558; Mon, 12 Dec 2011 10:33:07 -0800 (PST) Path: lh20ni14886pbb.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!news.mixmin.net!aioe.org!.POSTED!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: Does Ada support endiannes? Date: Mon, 12 Dec 2011 19:33:05 +0100 Organization: cbb software GmbH Message-ID: <1c2ax12bptm2g.gifwv5vndpxe$.dlg@40tude.net> References: <23835087-313f-427c-b37e-4ff1bdef9d57@r6g2000yqr.googlegroups.com> <20e631fc-e7b4-41ca-be0f-aab8be3f9a25@f33g2000yqh.googlegroups.com> <53n2sd7edt5i.1boh4452h0aks.dlg@40tude.net> <1kc5n51.ffg0umddufyfN%csampson@inetworld.net> Reply-To: mailbox@dmitry-kazakov.de NNTP-Posting-Host: QiAlLrcAYONeImYCedImjw.user.speranza.aioe.org Mime-Version: 1.0 X-Complaints-To: abuse@aioe.org User-Agent: 40tude_Dialog/2.0.15.1 X-Notice: Filtered by postfilter v. 0.8.2 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Date: 2011-12-12T19:33:05+01:00 List-Id: On Mon, 12 Dec 2011 09:07:24 -0800, Charles H. Sampson wrote: > Dmitry A. Kazakov wrote: > >> On Mon, 12 Dec 2011 04:46:22 -0800 (PST), Gerd wrote: >> >>> On 12 Dez., 12:27, "Dmitry A. Kazakov" >>> wrote: >>> >>> Any suggestion on how to convert, others than using "/" and "mod"? >> >> Why not to use them? It would be a bad idea trying to avoid them. >> >> It won't give you much performance, because memory mapping would require >> unpacking, alignment, checksum evaluation, stuff which would turn into >> extra copying. So why not just: >> >> type Octet is new Unsigned_8; >> type Word is new Unsigned_16; >> type Octet_Array is array (Positive range <>) of Octet; >> >> procedure Get_Little_Endian (Data : Octet_Array; Index : in out Integer; >> Value : out Word) is -- No extra copying >> begin >> Value := Word (Data (Index)) + Word (Data (Index + 1)) * 256; >> Index := Index + 2; >> end Get_Little_Endian; >> >> ... > > Don't you think this approach obscures what's going on, Dmitry, > thereby negating one of the design goals of Ada? No. The Ada's design goal was to allow the programmer to describe the semantics the data types involved and to program in that terms. Representation clauses rather defeat that idea than support it. The number read from the wire must look and feel as a number rather than some messy record, which cannot be a numeric parameter of a generic, has no 'Image, no meaningful literals etc... > Sure, most of us who > have bit-twiddled in the bad old days can figure out what's going on, or > at least convince ourselves that we've figured out what's going on, but > I much prefer the clarity of something like > > type Single_Precision is -- old IBM single-precision > record > Negative : Boolean; > Characteristic : Seven_Bit_Integer; > Mantissa : Twenty_Four_Bit_Fixed_Point; > end record; > > A_Variable : Single_Precision; And defining all arithmetic on it? Elementary functions including? I don't remember the IBM layout, but are you sure that you have got the order of fields right? What about the literals? No, I would never do it this way. In a comparable case: http://www.dmitry-kazakov.de/ada/components.htm#IEEE_754 I read IEEE 754 representations into the native floating point rather than messing up with representation clauses, even if the machine is natively IEEE 754. I just don't care. Granted, defining IEEE 754 as a record (Unchecked_Union?), denormalized numbers, NaN, +/-Inf, hidden mantissa bit, must be a HUGE fun! -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de