Subject: big/little endian

From: [email-masked] (Tor Arntsen)
Date: Thu, 24 Jun 1993 11:02:20 +0200

>>>>>On Jun 23,  2:34pm, Neil Russell wrote:
[...]
>> > *  The R3000 is able to be a little endian or a big endian machine.
>> >    Most operating systems that I've seen use the big endian mode, but
>> >    since linux runs on the 386, little endian may be more appropriate.
>> 
>> I don't know if it will make that much difference, but I suppose
>> little-endian is easiest.  Big endian will probably make talking to
>> ISA IO boards quite tricky.
>
>I don't like the idea of hardware swapping the bits, so this favours
>little endian, however, RISCos is big endian and has a few ISA bus
>slots; so the software must swap the bytes itself; Mmmm, this is the
>RISC way, after all...

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.. :-) :-)

Tor

---

From: [email-masked] (Jeremy Fitzhardinge)
Date: Thu, 24 Jun 1993 21:13:16 +1000 (EST)

> 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
#endif

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,
	J

---

From: [email-masked] (Neil Russell)
Date: Fri, 25 Jun 93 9:46:47 PDT

> the rest of the world.. :-) :-)

It's a matter of adding a single jumper to select what endian.  This board
will come configurable for either endian.  This is more a software issue,
and a debate as to whether this ISA bus should do byte swapping.

-- 
Neil Russell		(The wizard from OZ)
Pyramid Technology			Email:  [email-masked]
3860 N. First Street			Voice:  (408) 428-7302
San Jose, CA 95134-1702			  FAX:  (408) 428-8845