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.fn3LatRFkm9/xzEj7F2/NQ.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 09:20:36 +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: fn3LatRFkm9/xzEj7F2/NQ.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 Content-Language: en-US X-Notice: Filtered by postfilter v. 0.9.2 Xref: reader01.eternal-september.org comp.lang.ada:58064 Date: 2020-02-14T09:20:36+01:00 List-Id: 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. Most modern protocols would be very difficult if possible at all to implement using representation clauses. Do not do that. > Perhaps you have an atypical computing device that doesn't need DRAM for working copies of modifications to app data due to keeping everything in registers, SRAM cache, and/or directly-addressable nonvolatile storage. > >> The point is that application must keep its objects of an >> enumeration type using the representation chosen by the compiler. It is >> not programmer's business. > > 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. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de