comp.lang.ada
 help / color / mirror / Atom feed
From: "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>
Subject: Re: Simple Data Endianness
Date: Fri, 14 Feb 2020 09:20:36 +0100
Date: 2020-02-14T09:20:36+01:00	[thread overview]
Message-ID: <r25l8j$r35$1@gioia.aioe.org> (raw)
In-Reply-To: 243d7e76-a4e3-4974-88b2-5fd699755e9a@googlegroups.com

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


  reply	other threads:[~2020-02-14  8:20 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-13  9:42 Simple Data Endianness guijarrockguijarro
2020-02-13 11:10 ` Dmitry A. Kazakov
2020-02-13 15:12   ` Optikos
2020-02-13 15:28     ` Dmitry A. Kazakov
2020-02-13 16:47       ` Optikos
2020-02-13 17:29         ` Dmitry A. Kazakov
2020-02-13 20:36           ` Optikos
2020-02-14  8:20             ` Dmitry A. Kazakov [this message]
2020-02-14 17:25               ` Optikos
2020-02-14 20:22                 ` Dmitry A. Kazakov
2020-02-15 14:56                   ` Optikos
2020-02-13 15:44 ` Daniel
2020-02-13 15:57   ` Dmitry A. Kazakov
2020-02-14 16:52 ` Shark8
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox