Re: Simple Data Endianness

[Optikos <ZUERCHER_Andreas@outlook.com>]

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, 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 without packet loss).

> 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).  Likewise with memory-mapped register sets 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 802 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 struct type-casting technique that I mention here.  Your statement is pyrrhically true if one is expecting one representation-claused Ada record or one representation-rigged-up C struct to handle the entirety of header through all of the payload (through trailer, if any).  But that is not how this is done; a sequence of sometimes-differing and sometimes-the-same C structs are sequentially type-casted onto various portions of the datagram as it is written for transmittal or read upon receipt.

> > 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.

I utilize the dictionary definition of application:  to apply.  I utilize the dictionary definition of apply in reference to OSes, to libraries/frameworks/infrastructure, and to compiler-linker tool-chains:  to utilize their domainless potential to achieve a gain or benefit or outcome for a particular domain of human endeavor.  Applications are nothing more than a specific utilization of generic infrastructure to focus benefit on a particular human endeavor instead of the unrealized generic potential of the infrastructure.