> I don't have the numbers ready to hand, but it was not huge for most
> things, given the hack of running the disk wrong-endian. CPU overhead
> for non-disk DMA I/O was higher, of course, but there is no extra
> overhead for operations where all the arguments are in registers.
> (An integer in a register is the same, no matter which endian you are.)
> getpid(), for example, is unaffected. Similarly, read() and write()
> to disk are unaffected. On the other hand, stat() is a little slower.
> Note that endian data conversion is not blind byte swapping for
> structures such a stat. Instead, it is a field-by-field operation,
> since the MIPS reverse-endian mode affects only addressing, not the
> layout of the bytes of, say, an integer in memory. A 32-bit integer
> will be at a different offset from the base of the structure (4, say,
> instead of 0), but the byte order in memory will be the same. The
> byte numbering of memory is different, which is how it appears that
> the bytes have been swapped. The structure conversion routines can
> thus be compiled fairly efficiently, avoiding runtime structure offset
> calculations for the most part (except for arrays embedded in
> If this starts to look worth doing, I can supply more imformation,
> such as examples of how to efficiently convert structures.
This definately is worth doing. We have a couple of machines where we
can not configure byteorder of the kernel to big endian like DECstations
or the Acer PICA, essentially a downscaled Magnum with an Indy style L2
cache intended for NT. If we ever want to give them a chance to run
commercial software, then we need to go biendian. And we need to implement
it very clean or Linus will never accept the patches.
Luckily the functions get_user() and put_user in <asm/uaccess.h> do
already a large part of the work for us but nevertheless we need to
go through all the code once again. So maybe this is not something
for now but definately worth doing.