Re: Linux/IA-64 byte order

Re: Linux/IA-64 byte order

[Donald H. Gudehus]

>I write visualisation software for astronomy. This software is used
>all over the world, and often has to deal with very large
>datasets. It's not uncommon to "load" a dataset (a cube) but only view
>a small portion of it (a single plane (channel) of the cube). On
>big-endian machines I can avoid loading data and instead use memory
>mapping, because all the portable binary data formats are big-endian
>(FITS, Miriad and my own).

The SAD (Standard Astronomical Data) format is little-endian and was, in
fact, developed in your home country at Mt. Stromlo and Sliding Springs
Observatory.

>In the astronomy community, big-endian machines dominate (despite the
>growth of Linux/x86), and will always be favoured because the most
>important data format (FITS) is big-endian. When we tender for a new
>supercomputer, it is a requirement that it be big-endian.
>BTW: FITS has become a NIST standard and is widely used outside the
>astronomy community.


Here in the US, FITS can be big-endian or little-endian depending on
whether the keyword BYTEORDR equals BIG_ENDIAN or LITTLE_ENDIAN. 
Unfortunately this keyword is not always used because the byte order was
never specified in the original FITS description.  This naturally has
led to some confusion, with some facilities adopting big endian, some
adopting little endian, and some simply using the native format of the
machine.

Conceptually, it is more natural to have bits and bytes increase in
significance as system memory location (word address) increases.  This
is of course completely independent of graphical representations where
bit significance increases to the left, byte significance to the left or
right, and word significance to the left or right (four possible cases).

Donald Gudehus