Date: Thu, 4 Dec 1997 21:39:14 -0500 (EST)
From: "Ron G. Minnich" <rminnich@Sarnoff.COM>
On Thu, 4 Dec 1997, Alan Cox wrote:
> Yeuch ;). Can't you get your guys to put that in the MMU so you can have
> a little endian or big endian page ? I can see how you'd make lcc generate
> such output but not offhand gcc
If it's in the compiler:
1) htonx and ntohx are history
2) xdr is history
not a bad deal in my book. Put it in the MMU? 2^yeuch. :-)
Some architectures (I believe both PPC and UltraSPARC) provide three
mechanisms to specify endiannes for load and store operations.
1) In processor status register, a "everything foo-endian" bit
exists, there is also a "trap foo-endian" bit which states
which endianness exception handlers run with.
2) Load and Store instructions can specify "endianness attributes"
so for example on Sparc-V9 you can say
lda [%addr_reg] ASI_PL, %dest_reg
ASI means "Address Space Identifier" and PL means "Primary address
space Little-endian".
3) Per-page MMU endianness attribute bits. Those who casually
disassemble the solaris kernel now and again will notice that the
SLAB allocator in UltraSPARC kernels provides two sets of
interfaces for allocation, one gives you little endian chunks the
other gives you big-endian chunks. They implement this by frobbing
the PTE bits in the kernel mappings for these SLABs.
In the age of PCI, these three mechanism are super handy for
Big-Endian systems. You get the best of both worlds, of interest
namely is:
1) No byte swapping for IP networking header processing.
2) Direct access to legacy PCI cards, in the correct PCI
(ie. little endian) byte order, at zero cost.
3) Support for arbitrary endianness filesystem layouts, in
core, again at zero cost.
Later,
David S. Miller
davem@dm.cobaltmicro.com
|