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.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,9ae3749ddf1e6022 X-Google-Attributes: gid103376,public From: Kelly Grant Subject: Re: Endian and Ada Date: 1996/04/09 Message-ID: <1996Apr9.160008.27942@nosc.mil>#1/1 X-Deja-AN: 146569115 sender: news@nosc.mil references: <4kamb9$om2@flute.aix.calpoly.edu> content-type: text/plain; charset=us-ascii organization: Computer Sciences Corporation mime-version: 1.0 newsgroups: comp.lang.ada x-mailer: Mozilla 1.1 (Windows; U; 16bit) Date: 1996-04-09T00:00:00+00:00 List-Id: mporcell@flute.aix.calpoly.edu (Michael Anthony Porcelli) wrote: >I'm taking a computer architecture class and my eyes have been opened to the >incredible lack of progress that computer science has made in the area of >architecture-independant programming. One of the main problems that my >professor likes to point out the endian problem and the fact that so much >software is *not* endian-independant (due mainly to the widespread use of C >and C++). However, he is not familiar enough with Ada (nor am I) to know if >Ada is endian-independant. I'm almost positive that it's *possible* to make >endian-dependant code using unchecked programming (necessary for systems >writing). I was wondering, however, if the day-to-day Ada software out >there is written endian-independant (i.e. the language facilities used in >most day-to-day programming don't depend on whether your architecture is >"big" endian or "little" endian.) > We are currently facing this issue. We are working on control software on Intel platforms communicating with Motorola (and other) hardware on remote platforms. We are passing data across radio modems, and byte ordering is a concern. We are going to use "Network Byte Ordering" (I don't know whose standard this is, but in the Win32 environment (winsock specifically) we have methods like NtoHS (Network to Host System) that will know whether to swap bytes or not). I think the network byte ordering is big endian, but I don't know for certain. Of course you can try to implement certain tricks. For instance, you could define a standard that the first 4 byte value read is '1', and determine the endian-ness of the data by examining that known value. Perhaps the first entry in a file, or the first data packet shared between cooperating computers... It is *not* possible for a language to be endian-independant. Assumptions must be made and it is not possible to know which endian a particular file or packet is using just by looking at the data. The use of C or C++ is not an issue. When an application writes an multi-byte integer to a file, it will commit itself to big endian or little endian as soon as it is written, generally based on the base architecture. Kelly