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=unavailable autolearn_force=no version=3.4.4 Path: eternal-september.org!reader01.eternal-september.org!feeder.eternal-september.org!aioe.org!.POSTED.3d73Ybk3C5U4I2t8lv+lAQ.user.gioia.aioe.org!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: Simple Data Endianness Date: Fri, 14 Feb 2020 21:22:20 +0100 Organization: Aioe.org NNTP Server Message-ID: References: <2a19cdb1-6f01-4b1d-8597-b6ee21ed60ed@googlegroups.com> <9d6d22b8-3771-47ac-901f-e593237fe108@googlegroups.com> <243d7e76-a4e3-4974-88b2-5fd699755e9a@googlegroups.com> NNTP-Posting-Host: 3d73Ybk3C5U4I2t8lv+lAQ.user.gioia.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Complaints-To: abuse@aioe.org User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.4.2 X-Notice: Filtered by postfilter v. 0.9.2 Content-Language: en-US Xref: reader01.eternal-september.org comp.lang.ada:58072 Date: 2020-02-14T21:22:20+01:00 List-Id: On 2020-02-14 18:25, Optikos wrote: > On Friday, February 14, 2020 at 2:20:40 AM UTC-6, Dmitry A. Kazakov wrote: >> On 2020-02-13 21:36, Optikos wrote: >>> On Thursday, February 13, 2020 at 11:29:46 AM UTC-6, Dmitry A. Kazakov wrote: >>>> On 2020-02-13 17:47, Optikos wrote: >>>>> On Thursday, February 13, 2020 at 9:28:16 AM UTC-6, Dmitry A. Kazakov wrote: >>>>>> On 2020-02-13 16:12, Optikos wrote: >>>>>>> On Thursday, February 13, 2020 at 5:10:44 AM UTC-6, Dmitry A. Kazakov wrote: >>>>>>>> On 2020-02-13 10:42, guijarrockGuijarro wrote: >>>>>>>> >>>>>>>>> The problem I present today is related to the coexistence between big-endian and little-endian >>>>>>>>> application data. >>>>>>>> >>>>>>>> How low-level representation aspect might be relevant to application data? >>>>>>> >>>>>>> If the exchange of app data between 2 or more computers is word-wise binary instead of byte-wise >>>>>>> textual, such as via binary-formatted files or via binary-formatted datagrams/byte-streams as >>>>>>> payload of networking protocols. >>>>>> >>>>>> And how whatever protocol encoding format is could to "coexist" (?) with >>>>>> another itself (?) >>>>>> >>>>>> In any case it has nothing to do with application data as kept in the >>>>>> memory. >>>>> >>>>> Even your facetious example of app-data exchanged in Mayan numerals stored in GIF images needs to >>>>> be in DRAM for encoding and decoding the app-data to other modules of software elsewhere in the >>>>> app. >>>> >>>> Nope. >>> >>> I reiterate: Even your facetious example of app-data exchanged in Mayan numerals stored in GIF images needs to be in DRAM •••at some point, even if for a passing transient momentary instant (e.g., local to a procedure or function; or in a I/O buffer; or in preparation to conform to the GUI API's expectations)••• for encoding and decoding the app-data to other modules of software elsewhere in the app. >> >> No. That is technically wrong. A communication artifact does not need to >> be in the memory in order to be encoded or decoded. In fact it is rather >> an exception, even for integers. E.g. when an integer is encoded using a >> chained code. So, if GIFs were used for the purpose they would be >> encoded/decoded incrementally. > > No, you are factually incorrect in the technical domain. Even if streaming binary app-data piecemeal to evermore-accumulated content of a transient buffer, [...] I don't know what you mean. 1. That each bit on the wire arrives at the main memory? That depends on the hardware, but in general case it is wrong. As an example consider serial port. Stop bits, synchronization characters, parity bits never reach the memory, they are eaten by the hardware. 2. That each protocol artifact at some point is accumulated in the memory? This is also wrong. An analogy would be early multi-pass compilers. You imagine that protocols are implemented in a similar way. E.g. each protocol layer like each compiler pass generates some image in the memory or file on the disk. It is not so. Like with modern compilers all happens in parallel in some sort of conveyor. As an example consider CANOpen segmented SDO transfer: https://en.wikipedia.org/wiki/CANopen#Service_Data_Object_(SDO)_protocol Our CANOpen stack does not accumulate SDO payload before decoding it, it does that on the fly as new pieces arrive. So the payload is never stored complete in the memory. There is no point doing that. >> Most modern protocols would be very difficult if possible at all to >> implement using representation clauses. Do not do that. > > It is customary to implement networking protocols (in C) via representation-rigged-up structs that conform to network byte order (instead of, say, this processor's little-endianness). I am not talking about htons. I am talking about actually used protocols. There is much more in there than "byte order", and in many cases there is no byte order at all in the sense that no octet permutation will give you a valid machine representation of the thing. As example again consider ASN.1. E.g. ASN.1 length encoding. Feel free to provide an AI for a representation clause for ASN.1 integer and its length. Once ready, proceed to ASN.1 BIT STRING with its multiple segments. >>> Except when it is the programmer's business, such as to fully comply with the GIF format >>> specification's representation of GIF files interchanged between differing computers. >> >> That is not an *application* software. > > I utilize the dictionary definition of application: to apply. The term "application" used by the OP refers to "application software" https://en.wikipedia.org/wiki/Application_software Network protocol stacks is "system software". -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de