Simple Data Endianness

Simple Data Endianness

[guijarrockguijarro]

Hi, 


The problem I present today is related to the coexistence between big-endian and little-endian application data.

I have found a way that structures (records) are stored in memory according to one criterion or another (big-endian or little-endian).

Assuming that 'Date' is a structure type, I can use the following statements to indicate that I want them to be stored in memory as big-endian:

   for Date'Bit_Order use System.High_Order_First;
   for Date'Scalar_Storage_Order use System.High_Order_First;


My question appears when I have a simple type, such as an enumerated or an integer that occupies more than one byte and I need to instruct the compiler to store it in memory as a big-endian. Like this example:

   type Colour is (BLACK,YELLOW,WHITE,RED);  
   for Colour'SIZE use 32;

Is there any analogous way of doing this as in the case of compound types?


Thank you so much.

Re: Simple Data Endianness

[Dmitry A. Kazakov]

On 2020-02-13 10:42, guijarrockguijarro@gmail.com 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?

[...]

>     type Colour is (BLACK,YELLOW,WHITE,RED);
>     for Colour'SIZE use 32;
> 
> Is there any analogous way of doing this as in the case of compound types?

Should it include middle-endian packed binary-coded decimals with memory 
parity bits? (:-))

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

Re: Simple Data Endianness

[Optikos]

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.

> >     type Colour is (BLACK,YELLOW,WHITE,RED);
> >     for Colour'SIZE use 32;
> > 
> > Is there any analogous way of doing this as in the case of compound types?
> 
> Should it include middle-endian packed binary-coded decimals with memory 
> parity bits? (:-))

middle-endian:  Yes, if porting to PDP11, Honeywell 316, and the like. ;^)

parity bits:  Yes, if porting to Prime 50 series that had mark-parity ASCII characters 128 to 255 packed 2 at a time into 16-bit bytes.  ;^)

BCD: Yes, if the app data was written to a file in BCD, such as easily so by a BCD capable language (e.g., COBOL, Ada).  This one is less of a joke, because these COBOL-written app-data files are commonplace on IBM mainframes, especially if the new work is Ada on non-mainframes reading in the data downloaded from mainframes.

Re: Simple Data Endianness

[Dmitry A. Kazakov]

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.

BTW, supposing the exchange protocol happens to be Mayan numerals stored 
in GIF images. What representation clause we need in Ada for that?

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

Re: Simple Data Endianness

[Optikos]

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.  Implying that the app-domain must absolutely keep a single copy of its data without making any other copies of that app data is a strawman.  There will be user-inteface copies of substantially the same app-data.  There will be file-representation copies of substantially the same app-data.  There will be optimized numerical-processing copies of substantially the same app-data.  There will be general intra-app interchange processing of substantially the same app-data.  Anyone who thinks that there should be a single copy (or a Draconianly-minimized quantity of copies) of app-data needs to spend some time studying model-view-controller software architecture a bit more—or better yet MVVM, or better yet still VIPER.  VIPER takes minding-your-own-business regarding each* app-zone's differing needs regarding each* app-zone's copy/representation of the app-data to the Nth degree to achieve a wise separation of concerns and in turn to achieve collocation of reference when that is needed for efficiency in some app-zone that has collocation of reference as its concern.

* broadly categorized into 5 buckets, where each contains multiple/numerous OO class-trees that hand off to each other in disciplined ways:  view (V), presenter (P), interactor (I), entity (E), router (R)
https://cdn-images-1.medium.com/max/2000/1*YBRVqOQw0q1a5g1RFP6REQ.png

> BTW, supposing the exchange protocol happens to be Mayan numerals stored 
> in GIF images. What representation clause we need in Ada for that?

When Ada has Mayan numerals and GIF images as 1st-class citizens in the core language (i.e., not even the standard library), then, yes, Ada would need to have representation clauses for them.  Obviously, this would be a major disincentive to standardizing Mayan numeral and GIF images in the core language.  Perhaps you could submit an AI on an 01 April of some year to see how far the AI gets in the process.

Re: Simple Data Endianness

[Dmitry A. Kazakov]

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. 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. Representation clauses should never be 
misused for the purpose of external encoding even when that might per 
chance work. In most cases it does not, and it is good so.

>> BTW, supposing the exchange protocol happens to be Mayan numerals stored
>> in GIF images. What representation clause we need in Ada for that?
> 
> When Ada has Mayan numerals and GIF images as 1st-class citizens in the core language (i.e., not even the standard library), then, yes, Ada would need to have representation clauses for them.  Obviously, this would be a major disincentive to standardizing Mayan numeral and GIF images in the core language.  Perhaps you could submit an AI on an 01 April of some year to see how far the AI gets in the process.

I would rather go for Sumerian numerals first...

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

Re: Simple Data Endianness

[Optikos]

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.

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.

Re: Simple Data Endianness

[Dmitry A. Kazakov]

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

Re: Simple Data Endianness

[Optikos]

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.

Re: Simple Data Endianness

[Dmitry A. Kazakov]

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

Re: Simple Data Endianness

[Optikos]

On Friday, February 14, 2020 at 2:22:23 PM UTC-6, Dmitry A. Kazakov wrote:
> 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.

Now there is a correct statement.

Re: Simple Data Endianness

[Daniel]

i guess you want to serialize this data between 2 diferents CPUs families.

I think ADA only thought an automatic solution for mapped records.

You have two solutions.

First is really ugly: Put that type into a field of a single field mapped record.

Sencod is also ugly: Swap by your self the 4 bytes of this 32 bits type. Gnat have for example gnat.Byte_Swapping.Swap4 library to do it.

Regards.

Re: Simple Data Endianness

[Dmitry A. Kazakov]

On 2020-02-13 16:44, Daniel wrote:
> i guess you want to serialize this data between 2 diferents CPUs families.
> 
> I think ADA only thought an automatic solution for mapped records.
> 
> You have two solutions.
> 
> First is really ugly: Put that type into a field of a single field mapped record.
> 
> Sencod is also ugly: Swap by your self the 4 bytes of this 32 bits type. Gnat have for example gnat.Byte_Swapping.Swap4 library to do it.

Just use a reasonable network data distribution protocol or some custom 
serialization/deserialization method.

A protocol that uses 4 octets to transfer 4 enumeration states is not 
reasonable by any count.

In any case, never use protocol representations to store application 
data. This is an exemplary case of abstraction inversion.

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

Re: Simple Data Endianness

[Shark8]

On Thursday, February 13, 2020 at 2:42:14 AM UTC-7, guijarroc...@gmail.com wrote:
> Hi, 
> 
> 
> The problem I present today is related to the coexistence between big-endian and little-endian application data.

I think this depends on the use-case of the software. If everything is going to be Ada, I think all you need is to DSA things. -- See: https://video.fosdem.org/2020/AW1.125/ada_distribution.webm

You can also configure PolyORB to be both DSA and CORBA, IIRC. So, even if you can't directly distribute to the various architectures (which I would be surprised about) you *could* let CORBA handle the remote-calls/translations if you are going to use this with extant non-Ada software (assuming that there's an easily integrable CORBA there).

But if this is integrating new Ada into already extant [distributed] systems, you should take a look at how they're handling the communications. If it's something like UDP then your best bet is probably to go in and create the custom datagram packets yourself, if it's ASN.1 based communications then [IIRC] you can use this: https://www.thanassis.space/asn1.html

----
There's also the boring case of "reading/writing a binary file" -- if this is the case then you could probably do things via these representation clauses and stream attributes.