Subject: Questions?

From: Marc Karasek <[email-masked]>
Date: 06 Mar 2002 12:25:11 -0500

I have some general questions for all:

How many of you are involved with embedded linux development using a
MIPS processor? 

What endianess have you chosen for your project and why? 

If you have not guessed it, I am involved with a MIPS/Linux embedded
project and we are trying to determine if there are any pros or cons in
one endianess over the other.  

-- 
/*************************
Marc Karasek
Sr. Firmware Engineer
iVivity Inc.
[email-masked]
678.990.1550 x238
678.990.1551 Fax
*************************/

---

From: "Steven J. Hill" <[email-masked]>
Date: Wed, 06 Mar 2002 12:20:38 -0600

> How many of you are involved with embedded linux development using a
A fair number of us. Over a hundred easily.

> What endianess have you chosen for your project and why?
You don't really want to start this holy war, do you? That aside,
usually big endian is more useful in applications moving networking
type traffic or a fair amount of graphics processing. Little endian
is handy if you are porting applications from Windows or a lot of
your software is written in little endian.

That's my $.02.

-Steve

-- 
 Steven J. Hill - Embedded SW Engineer

---

From: Marc Karasek <[email-masked]>
Date: 06 Mar 2002 13:43:25 -0500

No, I have been involved with too many sorties in the war already.  I
was just asking if there was any issues with one side or the other from
a purely technical aspect.

---

From: Hartvig Ekner <[email-masked]>
Date: Wed, 6 Mar 2002 19:54:51 +0100 (CET)

It also depends on which new drivers you expect to use and thus need to
port from the x86 world. I can certainly tell you that we always start
off with LE for driver porting, for obvious reasons (x86, PCI), and then
go BE after that.

/Hartvig

---

From: Mike McDonald <[email-masked]>
Date: Wed, 06 Mar 2002 11:06:36 -0800

>Subject: Questions?
>From: Marc Karasek <[email-masked]>
>To: Linux MIPS <[email-masked]>
>Date: 06 Mar 2002 12:25:11 -0500

>What endianess have you chosen for your project and why? 

  LE. That's all the NEC VR41XX support so I had no choice.

  Mike McDonald
  [email-masked]

---

From: "Matthew Dharm" <[email-masked]>
Date: Wed, 6 Mar 2002 11:44:45 -0800

My company develops embedded MIPS systems, and Linux is one of our
supported operating systems.

We chose big-endian, mostly because it seemed the right choice given
the state of the tree.  Some customers have recompiled our code to run
little-endian with little problem, tho.

Matt

--
Matthew D. Dharm                            Senior Software Designer
Momentum Computer Inc.                      1815 Aston Ave.  Suite 107
(760) 431-8663 X-115                        Carlsbad, CA 92008-7310
Momentum Works For You                      www.momenco.com

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Marc Karasek
> Sent: Wednesday, March 06, 2002 9:25 AM
> To: Linux MIPS
> Subject: Questions?
>
>

---

From: "Bradley D. LaRonde" <[email-masked]>
Date: Wed, 6 Mar 2002 15:32:51 -0500

----- Original Message ----- 
From: "Marc Karasek" <[email-masked]>
To: "Linux MIPS" <[email-masked]>
Sent: Wednesday, March 06, 2002 12:25 PM
Subject: Questions?

> What endianess have you chosen for your project

little

> and why? 

1.  to match endianness with my x86 cross-dev build system
2.  hardware quirks

Regards,
Brad

---

From: Dominic Sweetman <[email-masked]>
Date: Thu, 7 Mar 2002 10:59:23 GMT

> What endianess have you chosen for your project and why? 

The MIPS world is irredemiably split, and the pull between SGI
(always big-endian, M68000 heritage and Sun compatibility) and Linux'
tendency to see the x86 as the universe has left Linux/MIPS split too.

As software tool and prototyping board supplier, we just know that
everything we do has to work either way.

If you can change that, it would be great! :-)

--
Dominic Sweetman, 
Algorithmics Ltd
The Fruit Farm, Ely Road, Chittering, CAMBS CB5 9PH, ENGLAND
phone: +44 1223 706200 / fax: +44 1223 706250 / direct: +44 1223 706205
http://www.algor.co.uk

---

From: Ralf Baechle <[email-masked]>
Date: Thu, 7 Mar 2002 14:07:54 +0100

> one endianess over the other.  

The MIPS ABI only covers big endian systems - every "real" MIPS UNIX
system is big endian.  Everything else is a GNU extension.  There is
hardly any reason to choose a particular byteorder as usually endianess
swapping takes so little CPU time that it isn't even meassurable but so
I'm told there are exceptions.  If portability of software you're
going to write wrt. external data representation (disk or network) is
of any importance then I suggest you use a system of the opposite
endianess which trip problems much faster.

  Ralf

---

From: Geert Uytterhoeven <[email-masked]>
Date: Thu, 7 Mar 2002 14:11:50 +0100 (MET)

> endianess which trip problems much faster.

I really like the last part! ;-)

BTW, you forgot to mention to go for a full 64-bit port, to trip even more
problems faster :-)

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email-masked]

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

---

From: Ralf Baechle <[email-masked]>
Date: Thu, 7 Mar 2002 14:18:11 +0100

> BTW, you forgot to mention to go for a full 64-bit port, to trip even more

Fortunately in practice that hasn't been a minefield as big as you'd imagine.

  Ralf

---

From: Richard Hodges <[email-masked]>
Date: Thu, 7 Mar 2002 09:56:58 -0800 (PST)

On Thu, 7 Mar 2002, Ralf Baechle wrote:

> I'm told there are exceptions.

To me, byte swapping on MIPS actually seems rather expensive.  The code
for htonl (linux/byteorder/swab.h) ends up something like this:

        srl     $5,$4,8
        andi    $5,$5,0xff00
        srl     $2,$4,24
        andi    $3,$4,0xff00
        or      $2,$2,$5
        sll     $3,$3,8
        or      $2,$2,$3
        sll     $4,$4,24

This may not be an issue if it is only needed a few times per packet, but
my system must byte-swap (LE to BE) about 500KB (or 4mb) per second.
Actually, I save a bit of work by combining the byte swapping with the
memory move, just after copy_from_user, and looks something like:

    unsigned char a, b, c, d, *mptr;
	a = mptr[0];
	b = mptr[1];
	c = mptr[2];
	d = mptr[3];
	mptr[0] = d;
	mptr[1] = c;
	mptr[2] = b;
	mptr[3] = a;

This method works, but it is still 8 instructions per word.  Yuck!  Does
anyone know of a _decent_ way to handle this on MIPS?

All the best,

-Richard

---

From: Dominic Sweetman <[email-masked]>
Date: Fri, 8 Mar 2002 09:58:47 GMT

Ralf Baechle ([email-masked]) writes:

> system is big endian.

Except Decstations.  And Sony NeWS (remember that one).  And anything
running on those NEC Vr41xx systems which were designed for WinCE and
don't run big-endian at all.  There never was a consensus...

Mapping the MIPS ABI to little-endian presents no problems, as far as
I know: obviously since it's a binary compatibility standard it has to
make a choice...

> There is hardly any reason to choose a particular byteorder as
> usually endianess swapping takes so little CPU time that it isn't
> even meassurable but so I'm told there are exceptions.

I think it's often done for software-portability reasons; sometimes
because some hardware works both ways but has some irritating flaw in
its less-favoured organisation.

System software (kernels, libraries) tends to work both ways, because
it's written by people who thought about it.  Huge applications which
have only ever run on x86 and friends often don't work.

Finding the problems faster is a counsel of perfection: in practice, a
lot of us just want something that works, tomorrow.

Swapping probably is an unmeasurable load: even if it takes 8-10
instructions per word on a 500MHz CPU that's 200Mbytes/s.  But it is
ugly, particularly when it's required to restore correct byte sequence
because of a naive hardware interface (one, for example, which
connects the MIPS CPU data lines to the same-numbered PCI ones...)

So there are arguments on both sides, and players in both camps.  I
believe it's too late to corral all MIPS/Linux activity into one
endianness or the other.

Embrace bi-endianness!