> Hi, all. I've been discussing the byte order that Linux/IA-64 will
> have with David Mosberger from HP. I'm arguing for big-endian to be
> used.
>
> I'd like to start a discussion and see if we can reach some reasonable
> consensus on whether big-endian is acceptable to the community. I
> think this is an important issue, as a little-endian Linux/IA-64 is
> going to make it a second choice for a significant number of
> people. This reason for this follows (from my orginal message to
> David):
>
> [Original message]
> 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).
>
> Being able to memory map a gigabyte dataset makes "loading" extremely
> fast. It also means you don't need stacks of swap space.
>
> 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.
>
> So, even though Linux/x86 is the most common Linux, I really don't
> think it justifies making Linux/IA-64 little-endian. Remember that
> there is already the difference in word size, so the two platforms are
> not going to have semi-seamless migration of data anyway. And for
> scientific applications, big-endian is the standard.
>
> If Linux/IA-64 is little endian, it will always be a second choice
> after Sun Sparc and SGI MIPS in the astronomy community and probably
> the science community as well.
>
> I implore you: please reconsider your decision. Don't punish Linux
> because of the x86 legacy.
> [End]
>
Little/big endian is determined by hardware. It is not a software
issue. Of course one could make a compiler put instructions in any
order, the natural order will be the order in which instructions
are fetched by the CPU from memory. Even if memory fetches are
long-longs, you will have to use what the CPU expects.
Then there is data. Again, the data is aligned and ordered however
the CPU expects it to be. You can't byte-swap and have math operations
on memory oprands mean much.
Suppose you have a magic switch that allows the CPU to fetch instructions
and manipulate data in any byte order. The problem still lies with
hardware. You need perhipherals for screen, disk, network, etc. These
would then determine the byte-order.
Then, suppose your perhipherals had magic switches also. Then what
would you do? Would you arrange the byte-order so 0xdeadface looked
like 0xdeadface in memory on a debugger? If so, you are now just
making a rule based upon preference. Instead, you should make a
rule based upon performance (like network communication).
Cheers,
Dick Johnson
***** FILE SYSTEM WAS MODIFIED *****
Penguin : Linux version 2.2.2 on an i686 machine (400.59 BogoMips).
Warning : It's hard to remain at the trailing edge of technology.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/