4.2.4 Byte Order

All information in computers is stored in the form of bits, where each bit can be either a 0 or a 1. Most modern computers use as the unit of memory a byte, which consists of eight bits and which can contain 256 different values. LUX’s data types (Numerical Data Types) all consist of an integral number of bytes. If a data value consists of more than one byte, then the byte that counts the smallest units of the value is called the least significant byte and the byte that counts the biggest units of the value is called the most significant byte. The bytes of a multi-byte data value can be stored in memory in different orders. The two byte orders used the most are the one in ascending order of significance, often referred to as little-endian (because you start at the end of the "little" values), and the one in descending order of significance, often called bigendian.

What happens if you try to read data on a bigendian machine that was written on a littleendian one? If you use any of the classical file I/O operations (i.e., following openr or openu), or use direct mapping of an array structure onto a disk file (i.e., assoc or fltfarr and its cousins), then LUX cannot automatically correct for the byte order discrepancy, because arbitrary files do not contain indications of how many bytes make up a value, and what their byte order might be. However, LUX provides the routine endian, which switches the byte order of the data in a variable from littleendian to bigendian or the other way around, so in this case you can read the data as usual and then switch its byte order if necessary.

If you use files that conform to LUX’s own FZ format (written using, e.g., fzwrite, fcwrite, or store) then the data’s type and byte order are included in the file’s header so any necessary corrections for byte order discrepancies are taken care of automatically. If you create such a file, then the data is always written in your machine’s native byte order.

The fzarr function which assigns an array structure to an FZ disk file does not correct for byte order discrepancies, even though the FZ file contains byte order information. This is because fzarr returns an appropriate file array (File Arrays) to access the file data and file arrays do not contain byte order information. This means that if you copy a file from a bigendian machine to a littleendian machine, or the other way around, then you cannot use a file array to access that data (except if you combine such access with the use of endian).

To find out if your computer is bigendian or littleendian, you can check the value of read-only global variable #msbfirst: if it is equal to 1, then the most significant byte comes first (i.e., your computer is bigendian), and if it is equal to 0, then the least significant byte comes first (it is littleendian).

Another way is to execute t,bmap(1). If the result is 0 0 0 1, then your computer is bigendian; if the result is 1 0 0 0 then your computer is littleendian.

See also: Disk File I/O, #msbfirst