Re: Simple Data Endianness

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On 2020-02-14 18:25, Optikos wrote:
> 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,

[...]

I don't know what you mean.

1. That each bit on the wire arrives at the main memory? That depends on 
the hardware, but in general case it is wrong. As an example consider 
serial port. Stop bits, synchronization characters, parity bits never 
reach the memory, they are eaten by the hardware.

2. That each protocol artifact at some point is accumulated in the 
memory? This is also wrong.

An analogy would be early multi-pass compilers. You imagine that 
protocols are implemented in a similar way. E.g. each protocol layer 
like each compiler pass generates some image in the memory or file on 
the disk. It is not so. Like with modern compilers all happens in 
parallel in some sort of conveyor.

As an example consider CANOpen segmented SDO transfer:

    https://en.wikipedia.org/wiki/CANopen#Service_Data_Object_(SDO)_protocol

Our CANOpen stack does not accumulate SDO payload before decoding it, it 
does that on the fly as new pieces arrive. So the payload is never 
stored complete in the memory. There is no point doing that.

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

I am not talking about htons. I am talking about actually used 
protocols. There is much more in there than "byte order", and in many 
cases there is no byte order at all in the sense that no octet 
permutation will give you a valid machine representation of the thing. 
As example again consider ASN.1. E.g. ASN.1 length encoding. Feel free 
to provide an AI for a representation clause for ASN.1 integer and its 
length. Once ready, proceed to ASN.1 BIT STRING with its multiple segments.

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

The term "application" used by the OP refers to "application software"

    https://en.wikipedia.org/wiki/Application_software

Network protocol stacks is "system software".

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de