Ralf Baechle (ralf@oss.sgi.com) writes: > The MIPS ABI only covers big endian systems - every "real" MIPS UNIX > 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! -- 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
