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,FREEMAIL_FROM autolearn=unavailable autolearn_force=no version=3.4.4 X-Received: by 2002:a37:948:: with SMTP id 69mr995055qkj.258.1581626170382; Thu, 13 Feb 2020 12:36:10 -0800 (PST) X-Received: by 2002:a05:6830:1d7b:: with SMTP id l27mr13825360oti.251.1581626170033; Thu, 13 Feb 2020 12:36:10 -0800 (PST) Path: eternal-september.org!reader01.eternal-september.org!feeder.eternal-september.org!news.gegeweb.eu!gegeweb.org!usenet-fr.net!proxad.net!feeder1-2.proxad.net!209.85.160.216.MISMATCH!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Thu, 13 Feb 2020 12:36:09 -0800 (PST) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: google-groups.googlegroups.com; posting-host=47.185.239.228; posting-account=zwxLlwoAAAChLBU7oraRzNDnqQYkYbpo NNTP-Posting-Host: 47.185.239.228 References: <2a19cdb1-6f01-4b1d-8597-b6ee21ed60ed@googlegroups.com> <9d6d22b8-3771-47ac-901f-e593237fe108@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <243d7e76-a4e3-4974-88b2-5fd699755e9a@googlegroups.com> Subject: Re: Simple Data Endianness From: Optikos Injection-Date: Thu, 13 Feb 2020 20:36:10 +0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Xref: reader01.eternal-september.org comp.lang.ada:58058 Date: 2020-02-13T12:36:09-08:00 List-Id: On Thursday, February 13, 2020 at 11:29:46 AM UTC-6, Dmitry A. Kazakov wrot= e: > On 2020-02-13 17:47, Optikos wrote: > > On Thursday, February 13, 2020 at 9:28:16 AM UTC-6, Dmitry A. Kazakov w= rote: > >> 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 b= ig-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 d= atagrams/byte-streams as > >>> payload of networking protocols. > >> > >> And how whatever protocol encoding format is could to "coexist" (?) wi= th > >> another itself (?) > >> > >> In any case it has nothing to do with application data as kept in the > >> memory. > >=20 > > Even your facetious example of app-data exchanged in Mayan numerals sto= red in GIF images needs to > > be in DRAM for encoding and decoding the app-data to other modules of s= oftware elsewhere in the > > app. >=20 > Nope. I reiterate: Even your facetious example of app-data exchanged in Mayan nu= merals stored in GIF images needs to be in DRAM =E2=80=A2=E2=80=A2=E2=80=A2= at some point, even if for a passing transient momentary instant (e.g., loc= al to a procedure or function; or in a I/O buffer; or in preparation to con= form to the GUI API's expectations)=E2=80=A2=E2=80=A2=E2=80=A2 for encoding= and decoding the app-data to other modules of software elsewhere in the ap= p. Perhaps you have an atypical computing device that doesn't need DRAM for wo= rking copies of modifications to app data due to keeping everything in regi= sters, SRAM cache, and/or directly-addressable nonvolatile storage. > The point is that application must keep its objects of an=20 > enumeration type using the representation chosen by the compiler. It is= =20 > not programmer's business. Except when it is the programmer's business, such as to fully comply with t= he GIF format specification's representation of GIF files interchanged betw= een differing computers.