[Top] [All Lists]

Re: A question about architecture and byte order with RPMs

To: rminnich@Sarnoff.COM
Subject: Re: A question about architecture and byte order with RPMs
From: "David S. Miller" <>
Date: Thu, 4 Dec 1997 18:59:51 -0800
In-reply-to: <Pine.SUN.3.91.971204213811.11147A-100000@terra> (rminnich@Sarnoff.COM)
References: <Pine.SUN.3.91.971204213811.11147A-100000@terra>
   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.

David S. Miller

<Prev in Thread] Current Thread [Next in Thread>