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: a07f3367d7,43ad9ab56ebde91c X-Google-Attributes: gida07f3367d7,public,usenet X-Google-NewGroupId: yes X-Google-Language: ENGLISH,ASCII-7-bit Received: by 10.68.212.232 with SMTP id nn8mr15656217pbc.1.1324849366281; Sun, 25 Dec 2011 13:42:46 -0800 (PST) MIME-Version: 1.0 Path: lh20ni64033pbb.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: Sun, 25 Dec 2011 15:42:45 -0600 Newsgroups: comp.lang.ada Subject: Re: Does Ada support endiannes? From: csampson@inetworld.net (Charles H. Sampson) Date: Sun, 25 Dec 2011 13:42:45 -0800 Message-ID: <1kcu0zg.r0yxxk4341xyN%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> <1kc8f2j.132xw621jmu761N%csampson@inetworld.net> <16jibtpb9f2o4.1pf3ro8hb8qq2.dlg@40tude.net> <1kcakce.17lpouc1o2nz0gN%csampson@inetworld.net> <1ol1w9audpvta.1drukev3uwfoe.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-AYEJJbnH8LDgKkh0FL+HC5+37sPrWtD6eb2El8IKDNK4ZU6u8WWgzXHZTCYJbSA9c2+YGBF3LSyQsWI!O2VrroLdsy3TJE5NyDgoDZPw2UC/EQALoKox+drqUf6payqAQK36rGUqVmRi1wE+XRx/FfWBMtOR!n0WD7FBfVTtap/NpUFCz4D67pwY= 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: 7629 Date: 2011-12-25T13:42:45-08:00 List-Id: Dmitry A. Kazakov wrote: > 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. He's baaaaack! Sorry to leave such a time gap in this thread but I had to find time during this busy season to commune with the LRM at bit. > > 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. I'm not clear on what you mean by "representation clauses ... tend to convert things as a whole". Representation clauses don't convert anything. They just specify how the bits are laid out in memory. It doesn't matter how those bits got there. In the present case, probably a low-level routine was called telling it to place the incoming packet at a certain place in memory. It's only after the bits are in the proper place that any conversion takes place. For example, to change the endianess of a two-byte word, I might write something like Internal_Small_Word := 256 * Incoming.Byte_2 + Byte_1; It's more than likely that I would use a representation clause for Internal_Small_Word also and just do two assignments: Internal_Small_Word.Byte_1 := Incoming.Byte_2; Internal_Small_Word.Byte_2 := Incoming.Byte_1; It won't surprise you when I say that I think the latter is much clearer as to intent and meaning than any arithmetic manipulating, including my former example. Data corruption is handled by whatever mechanism is in the data packets to guard against corruption. In my experience that was usually a pretty simple-minded checksum. Whenever a corrupted packet was detected, all of its data were thrown away. As to checks of incoming data before storing, I usually let Ada do that for me by properly defining the target data type. I remember having to occasionally use 'Valid but I don't remember exactly when. I think it had something to do with holey enumerations. > >> 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. You've given rep clauses more semantics than the LRM. They simply specify how bits are laid out. I (and the people I lead) avoid storage unit issues by writing component clauses of the form for Component use at 0 range ... That is, the layout is specified relative to the beginning of the record. Comments usually tie this to the document that specified the data layout. I could also get around native machine endianess by specifying the bit order; for some reason I didn't. The down side of this form of component clause is that, without the comments, it is a little obscure. I decided to make that tradeoff in order to get better native machine transportability. > The rule of thumb: representation clauses shall be used exclusively for the > machine hardware. This is the only legitimate case for them. Isn't that what I've been advocating? Using representation clauses when the hardware of one machine doesn't match the hardware of another? I hope nothing I've written was interpreted as meaning you should sprinkle rep clauses around like holy water. I religiously avoid using them except when absolutely necessary. (Your meaning of "absolutely necessary" might differ from mine.) Charlie -- Nobody in this country got rich on his own. You built a factory--good. But you moved your goods on roads we all paid for. You hired workers we all paid to educate. So keep a big hunk of the money from your factory. But take a hunk and pay it forward. Elizabeth Warren (paraphrased)