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,43ad9ab56ebde91c X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Received: by 10.68.189.194 with SMTP id gk2mr648647pbc.3.1323839948818; Tue, 13 Dec 2011 21:19:08 -0800 (PST) MIME-Version: 1.0 Path: lh20ni20313pbb.0!nntp.google.com!news2.google.com!Xl.tags.giganews.com!border1.nntp.dca.giganews.com!nntp.giganews.com!local2.nntp.dca.giganews.com!nntp.nethere.com!news.nethere.com.POSTED!not-for-mail NNTP-Posting-Date: Tue, 13 Dec 2011 23:19:08 -0600 Newsgroups: comp.lang.ada Subject: Re: Does Ada support endiannes? From: csampson@inetworld.net (Charles H. Sampson) Date: Tue, 13 Dec 2011 21:19:07 -0800 Message-ID: <1kc8f2j.132xw621jmu761N%csampson@inetworld.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> <1c2ax12bptm2g.gifwv5vndpxe$.dlg@40tude.net> User-Agent: MacSOUP/2.8.2 (Mac OS X version 10.4.11 (PPC)) X-Usenet-Provider: http://www.giganews.com X-Trace: sv3-cFMVwmz4NO+U1jSL7Yum3RDKlx3111P/gkoOFtjYnCtSCT3mUMXxjMHIvd5Mqp36lhzEqaGdLu98rBL!jPgymIi3BrkiKFOtYGzfOVPG49++X1qzp/C8lTuQcCkM/5oluUoNmPIO0VfR8rd+It4uU1nmVbcR!sBIaazdq0FDXikY5cyB4nyhm4ZokYQ== X-Complaints-To: abuse@nethere.com X-DMCA-Complaints-To: abuse@nethere.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.40 X-Original-Bytes: 6595 Date: 2011-12-13T21:19:07-08:00 List-Id: Dmitry A. Kazakov wrote: > 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... I think I see the place where we have the greatest disagreement in concept. To me, in general, data coming "over a wire" are just a stream of bits until we have interpreted them and found out what they mean. (The primary, and maybe the only, exception would be a homogenous data stream. No interpretation is required.) So for me, again in general, there is no such idea as reading a number from such data. As a result, I need all sorts of ways of converting bit streams to various internal data types. > > 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? If the a bit stream is interpreted as a target machine native number, then I have to use two views into each variable of that numeric type. One view looks at it as a native number and the other view would show its component structure. All the number's operations and elementary functions are available by using the native number view. These two views are a form of aliasing, which I don't like very much at all. This can be minimized through the use of conversion functions, limiting the aliasing to the body of the functions. There's no execution penalty to this approach because the conversion functions are easily inlined. At that requires a bit mor writing than your approach, Dmitry, but that's o. k. with me. The design of Ada was permitted to require "extra" writing for the purpose of clarity of code. If I'm willing to write voluminous comments to document the source code, and I am, I don't begrudge a few keystroke when writing code itself. I'm 99.97% sure that I have the IBM single-precision layout correct, including the order, but it doesn't matter. In practice I would always use a representation specification. I always use rep specs when I'm defining a type whose bit layout (or encoding, for an enumeration type) has been specified. In the case of an enumeration type I do that even if the specification is the LRM-defined one. My coding style is that a rep spec means that the layout or encoding has been specified somewhere. If it hasn't been, I'm pretty rigorous about letting the compiler choose the representation. > 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! I did it and it wasn't a big deal at all. Charlie -- [A certain TV newsreader] had a role to play: presenter of the Other Side of the Argument, to whom fair-minded people were obligated to pay heed, no matter what nonsense he spouted. Charlie Pierce, Idiot America