[Top] [All Lists]

Re: big/little endian

To: tor@tss.no (Tor Arntsen)
Subject: Re: big/little endian
From: jeremy@sw.oz.au (Jeremy Fitzhardinge)
Date: Thu, 24 Jun 1993 21:13:16 +1000 (EST)
Cc: riscy@pyramid.com
In-reply-to: <9306240902.AA09427@unas.tss.no> from "Tor Arntsen" at Jun 24, 93 11:02:20 am
Organization: Softway Pty Ltd
Tor Arntsen bubbles:

> I would prefer big endian, but I have no strong objections (that means, I will
> buy the board anyway) if it ends up the other way (the DEC/Intel way vs. 
> the rest of the world.. :-) :-)

Given a free hand, I would prefer big endian.  However, I think there
are a few compelling reasons to go little endian -- all to do with
compatability with the Intel version.  Choosing bigendian wouldn't
make it impossible, but it does offer a whole pile extra places for
things to go wrong.  If we can make code like this work without
problems, wrong as it is, it would be helpful:

#ifdef linux    /* linux runs on intel only */
#define little_endian

There are a number of places where it would be good to keep the same format
to the bit level on all Linux architectures:
        Executable/Object files
                Obviously there are going to be CPU related differences,
                but programs should be able to manipulate files from any
                type of host.  Plan 9 handles this by keeping a strict
                byte order regardless of the native one.  ELF does it
                by storing the byte order in the file.  Either way,
                conversion has to be done explicitly if its wrong.  With
                luck we can expect ELF to be quite standard in linux soon,
                and it will make the multiple CPU type problem easier to
                deal with.  Gcc copes with cross compilation quite well.
        Filesystem meta-data
                It would be really good to be able to take filesystems and
                use them on any type of machine.  It would be doubly good
                if the filesystem code doesn't have to do much to do it.
        Network data
                This is universally big-endian.  Little endian machines
                just have to cope.  It is not a large overhead generally.

There are other data representation issues other than byte sex, like
alignment constraints.  This would probably be a more subtle problem
for programs that just write structures into files expecting them to
be read back in again.

I think it is important to make linux run on both intel and mips chips
with as much compatability as possible, rather than taking the approach
of getting the intel source as a base and forking the development at
that point.  The porting effort should find all the intel specific bits
and isolate them, making sure that gets into Linus' base source.
There are always going to be many more people using and hacking intel
linux boxes over any other, and we want to make sure that kernel changes
are as widely useful as possible.  We should be able to also get a higher
level of source compatability (near 100%).

Mips ABI compliance doesn't seem very important to me.  There isn't
much commercial stuff being distributed for mipsen in binary form,
so far as I know.  Certainly a package we use here is not being
distributed for the Mips machines (get a Sparc or Intel they say...).

Intel ABI compliance may be possible later.  It would probably involve
interpreting the main code body, and catching syscalls and library
calls for the interface.  Could be a simple matter of programming,
could be non-trivial.  Little endianess would certainly help.

Also, it would be nice to get the experiences of those doing 68k ports.
I'm told they exist, but I have no references.  Does anyone have names
or addresses?

Gotta rush,


<Prev in Thread] Current Thread [Next in Thread>