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.205.136.10 with SMTP id ii10mr88794bkc.7.1323942408594; Thu, 15 Dec 2011 01:46:48 -0800 (PST) Path: jh9ni13980bkb.0!nntp.google.com!news2.google.com!goblin3!goblin.stu.neva.ru!usenet.pasdenom.info!aioe.org!.POSTED!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: Does Ada support endiannes? Date: Thu, 15 Dec 2011 10:46:26 +0100 Organization: cbb software GmbH Message-ID: <1ol1w9audpvta.1drukev3uwfoe.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> <1c2ax12bptm2g.gifwv5vndpxe$.dlg@40tude.net> <1kc8f2j.132xw621jmu761N%csampson@inetworld.net> <16jibtpb9f2o4.1pf3ro8hb8qq2.dlg@40tude.net> <1kcakce.17lpouc1o2nz0gN%csampson@inetworld.net> Reply-To: mailbox@dmitry-kazakov.de NNTP-Posting-Host: FbOMkhMtVLVmu7IwBnt1tw.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-15T10:46:26+01:00 List-Id: On Thu, 15 Dec 2011 01:14:15 -0800, Charles H. Sampson wrote: > Dmitry A. Kazakov wrote: > >> I think the problem here is not the volume of the code, but an untyped >> nature of it. > > My code gets "typed" as soon as possible, as soon as I can > recognize what its type is supposed to be. The reason I wrote _typed_ > in quotes is that a stream of bits, where I start, is typed: > > type Bit is range 0 .. 1; > for Bit'Size use 1; > type Bit_Stream is array (Positive range <>) of Bit; > pragma Pack (Bit_Stream); In order to make this working with representation clause you have to get bits out of this stream and store them into a properly aligned array of Storage_Unit. Doing so, you will have to take into account native storage unit bit endianness, which may differ from the endiannes of the protocol. Furthermore, since almost all protocols are octet-oriented rather than bit-oriented, you will need to decode the protocol's stream of octets into bits and then recode that into an array of storage units to apply a representation clause on that. A rationale for such an exercise is beyond me, but certainly this is not what anybody could call "simple" or "readable." > Sometime the time between the IO and the conversion is longer than > you might hope, at least on the input side. Referring again to the last > system I worked on, we often had to read part of the input to determine > the length of the incoming bit string, then read the rest in, and then > begin the checking to determine exactly what we had. Yes, and this is yet another argument against representation clauses which tend to convert things as a whole. The problem is that protocols are using finer grained elements, that data might be corrupted, not ready as a whole etc. Using representation clauses you will have problems with validating data after conversion. You must ensure that no invalid bit pattern may become a valid value after re-interpretation using a representation clause. When using arithmetic of octets this is done in the course of conversion, almost automatically. With representation clauses you would likely have to add some extra checks before storing the data and after the re-interpretation. >> As a by-product you get a highly portable code as Gautier pointed out in >> another response. > > I don't understand this claim of highly portable code without using > a rep spec. The semantics of a representation clause depends on the native machine bit and storage unit endianness, the size of the storage unit, alignment constraints. The semantics of arithmetic operations and shifts is fully machine-independent. The rule of thumb: representation clauses shall be used exclusively for the machine hardware. This is the only legitimate case for them. > All I'm trying to do is lead > you to enlightenment by exposing you to my clearly superior ideas. :-) (:-)) -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de