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:a05:6214:1634:: with SMTP id e20mr3110306qvw.205.1581701124935; Fri, 14 Feb 2020 09:25:24 -0800 (PST) X-Received: by 2002:a9d:53cb:: with SMTP id i11mr3282324oth.158.1581701124625; Fri, 14 Feb 2020 09:25:24 -0800 (PST) Path: eternal-september.org!reader01.eternal-september.org!feeder.eternal-september.org!aioe.org!peer03.am4!peer.am4.highwinds-media.com!news.highwinds-media.com!tr3.eu1.usenetexpress.com!feeder.usenetexpress.com!tr3.iad1.usenetexpress.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Fri, 14 Feb 2020 09:25:24 -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> <243d7e76-a4e3-4974-88b2-5fd699755e9a@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: Subject: Re: Simple Data Endianness From: Optikos Injection-Date: Fri, 14 Feb 2020 17:25:24 +0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Received-Bytes: 6851 X-Received-Body-CRC: 1904130036 Xref: reader01.eternal-september.org comp.lang.ada:58071 Date: 2020-02-14T09:25:24-08:00 List-Id: 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. Kazak= ov 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 applicati= on data? > >>>>> > >>>>> If the exchange of app data between 2 or more computers is word-wis= e 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 th= e > >>>> memory. > >>> > >>> Even your facetious example of app-data exchanged in Mayan numerals s= tored 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. > >=20 > > I reiterate: Even your facetious example of app-data exchanged in Maya= n numerals stored in GIF images needs to be in DRAM =E2=80=A2=E2=80=A2=E2= =80=A2at 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)=E2=80=A2=E2=80=A2=E2=80=A2 for en= coding and decoding the app-data to other modules of software elsewhere in = the app. >=20 > No. That is technically wrong. A communication artifact does not need to= =20 > be in the memory in order to be encoded or decoded. In fact it is rather= =20 > an exception, even for integers. E.g. when an integer is encoded using a= =20 > chained code. So, if GIFs were used for the purpose they would be=20 > 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 b= uffer, the buffer (and its contents, hence the app-data therein) exists in = DRAM (except on exotic computing devices, such as network processors, that = refrain from utilizing DRAM during normal operations post-bootstrap, due to= keeping everything in registers or SRAM such as to process at line rate wi= thout packet loss). > Most modern protocols would be very difficult if possible at all to=20 > 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, thi= s processor's little-endianness). Likewise with memory-mapped register set= s in ASICs and FPGAs (instead of piecemeal-injected I/O ports that are not = memory mapped into the same address space as DRAM). IETF's RFCs and IEEE 8= 02 and ITU-T go to great effort to reveal how to visualize such typecasting= of these representation-rigged-up structs for each portion of a datagram. = NPs process at line rate all of these via the representation-rigged-up str= uct type-casting technique that I mention here. Your statement is pyrrhica= lly true if one is expecting one representation-claused Ada record or one r= epresentation-rigged-up C struct to handle the entirety of header through a= ll of the payload (through trailer, if any). But that is not how this is d= one; a sequence of sometimes-differing and sometimes-the-same C structs are= sequentially type-casted onto various portions of the datagram as it is wr= itten for transmittal or read upon receipt. > > Perhaps you have an atypical computing device that doesn't need DRAM fo= r working copies of > > modifications to app data due to keeping everything in registers, SRAM = cache, and/or > > directly-addressable nonvolatile storage. > >=20 > >> The point is that application must keep its objects of an > >> enumeration type using the representation chosen by the compiler. It i= s > >> not programmer's business. > >=20 > > Except when it is the programmer's business, such as to fully comply wi= th the GIF format > > specification's representation of GIF files interchanged between differ= ing computers. >=20 > That is not an *application* software. I utilize the dictionary definition of application: to apply. I utilize t= he dictionary definition of apply in reference to OSes, to libraries/framew= orks/infrastructure, and to compiler-linker tool-chains: to utilize their = domainless potential to achieve a gain or benefit or outcome for a particul= ar domain of human endeavor. Applications are nothing more than a specific= utilization of generic infrastructure to focus benefit on a particular hum= an endeavor instead of the unrealized generic potential of the infrastructu= re.