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.74.201 with SMTP id w9mr16933954pbv.0.1324896439999; Mon, 26 Dec 2011 02:47:19 -0800 (PST) Path: lh20ni66016pbb.0!nntp.google.com!news1.google.com!goblin2!goblin.stu.neva.ru!aioe.org!.POSTED!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: Does Ada support endiannes? Date: Mon, 26 Dec 2011 11:47:15 +0100 Organization: cbb software GmbH Message-ID: <1tegoy0w6pnqm$.qr7gobrrq1t6$.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> <1ol1w9audpvta.1drukev3uwfoe.dlg@40tude.net> <1kcu0zg.r0yxxk4341xyN%csampson@inetworld.net> Reply-To: mailbox@dmitry-kazakov.de NNTP-Posting-Host: PPt+vSuBRqtkVsMLa1J3Dg.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-26T11:47:15+01:00 List-Id: On Sun, 25 Dec 2011 13:42:45 -0800, Charles H. Sampson wrote: > 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. But you want to use them for conversions. You somehow put raw data there and then reinterpret that as an integral ADT object, usually an integer. What about a task object? Consider an agent-based application using some protocol to transport agents (tasks) over the network. Would you reconstruct an agent from bits and bytes using a representation clause? (:-)) > 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. No. The first variant follows the mathematical definition of how an integer of the range 0 .. 2**16 - 1 is encoded as a sequence of octets (integers range 0 .. 2**8 - 1). Your code uses obscure assignments to some fields of some record type, which connection to the mathematical definition of an encoded number is not clear to the reader, as well as the correctness of the code, because the order of bytes and gaps between them is specified somewhere else by a representation clause. Note also that all examples you and others have so far provided, go no further swapping bytes and trivial bit fields extraction. This is too little for real-life applications. Consider a PT100 WAGO Modbus module. It delivers a WORD (two bytes) in so-called Siemens format. 12 MSBs encode the value from -200 to 883 degree Celsius represented as 0400..7FF8. Bigger and lesser values are cropped. The 4 LSBs bits are the diagnostics bits (curcuit open/close etc). You could not handle this using a representation clause in one step. You will have first to swap bytes to build a 16 bit integer and use it to obtain the temperature masking and shifting. Or, first reorder and extract 12 bits, extract 4 bits, check, recode 12 bits into value. In both cases arithmetical operations are unavoidable. > Data corruption is handled by whatever mechanism is in the data > packets to guard against corruption. As I said, you need something to add, in order to check validity of the values obtained from the conversion. X'Valid is no help in the examples like above, when values are saturated and/or additional bits or patterns are used to indicate validness. Another example chain codes. E.g. the following encoding of cardinal numbers: 0 -> 2#0000_000# 1 -> 2#0000_0001# ... 127 -> 2#0111_1111# 128 -> 2#1000_0000# 2#0000_0001# 129 -> 2#1000_0001# 2#0000_0001# ... 4095 -> 2#1111_1111# 2#0111_1111# 4096 -> 2#1000_0000# 2#1000_0000# 2#0000_0001# ... [Chain codes are used when the upper bound of the transported number is unspecified and it is expected that lesser values are more frequent than bigger ones. UTF-8, is chain code.] Care to write a representation clause for the above? >> 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? In that case we are in agreement that they should not be used for handling I/O protocols. The only useful examples of representation clauses I saw were descriptions of machine registers, e.g. the bits of the processor status word, of the memory mapping registers etc. IMO, this is the only legitimate use for them: systems programming, machine-specific, once in 10 years or never. > Using representation clauses > when the hardware of one machine doesn't match the hardware of another? All sorts of I/O: reading data from a hardware port, from a socket, from dual-ported shared memory etc. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de