Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!elroy.jpl.nasa.gov!ncar!midway!quads.uchicago.edu!rtp1
From: rtp1@quads.uchicago.edu (raymond thomas pierrehumbert)
Newsgroups: comp.arch
Subject: Re: endian etc
Keywords: endianness??, cache
Message-ID: <1991May13.151652.12704@midway.uchicago.edu>
Date: 13 May 91 15:16:52 GMT
References: <2496@cybaswan.UUCP> <3407@spim.mips.COM> <181@titccy.cc.titech.ac.jp>
Sender: news@midway.uchicago.edu (NewsMistress)
Organization: University of Chicago
Lines: 16

The real solution to a bi-endian environment is to have a good
typed file system, like Apollo Domain or the Mac Finder.  Then,
a file could have header information that tells what its
endian-ness is.  Further, for data files that are to be
shared with multiple environments, the data could then
either be converted to the native form "on the fly" (a
performance hit), or the data could be maintained in the
file in two copies with different endian-ness (a disk hog,
but disk space is cheap, what?).

I think most people who need dual-endian-ness want to share
data files, not binaries.  At least that is my experience.
What we do to get around this is to use transportable
self-describing file formats, notably HDF and netCDF.  I'd
like to see these built into an OS someday, as they're so
terribly useful.