Path: utzoo!attcan!uunet!zaphod.mps.ohio-state.edu!mips!lloyd!cprice From: cprice@mips.COM (Charlie Price) Newsgroups: comp.arch Subject: Re: R3000A question ??? Message-ID: <42971@mips.mips.COM> Date: 9 Nov 90 09:30:20 GMT References: <14900018@hpdmd48.boi.hp.com> <42474@mips.mips.COM> <1092@dg.dg.com> Sender: root@mips.COM Reply-To: cprice@mips.COM (Charlie Price) Organization: MIPS Computer Systems Lines: 116 > >From: lewine@dg-rtp.dg.com (Donald Lewine) > Message-ID: <1092@dg.dg.com> > > In article <42474@mips.mips.COM>, mash@mips.COM (John Mashey) writes: > |> In article <14900018@hpdmd48.boi.hp.com> sritacco@hpdmd48.boi.hp.com > (Steve Ritacco) writes: > |> > |> R6000s, and R3000As have a "RE" (Reverse Endian) status bit, in > addition, > |> part of the coprocessor 0 status register. > |> If the kernel sets this bit, its own execution is unaffected, > |> but if it transfers to user state with the bit set, the user process > |> runs in the Reverse byte order compared to the kernel. Executive summary: This "feature" does no magic. Yes, using it would definitely be hard work. Technophile discussion: MIPS processors have always been either endian -- the CPU chip gets told at reset time which byte-sexual-orientation to believe in. The memory system is always word oriented. To implement a byte-sexual-orientation with a word oriented memory system the CPU has a simple view of the world: if a partial-word (byte, half-word, or triplet) load or store happens, a "load-aligner" figures out which bytes of the memory/register to put into the correct bytes of the register/memory. To be a bit more concrete, a "load byte" instruction fetches a word from memory and then plucks some byte from that word and "shift align"s it into the low-order byte of the target register. Until the 'RE' bit was added to the R6000 and R3000A, the processors were unable to change their byte-sexual-orientation on the fly. The 'RE' bit basically allows the OS to specify the way the load-aligner works when the processor is executing in user mode. The feature is not something radically new, it doesn't do more than provide more complete access to the base functionality of the hardware. > Does this really work? The kernel has to remap the bytes in > all data structures that go between the user and the kernel. That > sounds like a lot of work. It does what it advertises. If that is "work"ing, then yes. In the most wonderful of all possible worlds, the 'RE' bit woud would allow an OS on a single machine to simultaneously run binaries that believed in big-endian and little-endian universes. Yes, that is a whole lot of work. > What happens with data files? If I have a FORTRAN program that > I compiled on a machine with on Endian-ness, can it read binary > data on another machine. What happens if I recompile the > program on the target machine? Given the way the "endian"ness of the processors works, converting disk-file data, for instance, between native byte order and "guest" byte order would have to be done explicitly by the OS. You can only have one simple view of data work between endian universes. You make text files work, obviously, since binary data is just text that has decide to be obscure and terse. In this case, the OS has to flip words around before feeding disk data to a "reverse" endian process. > Also, what happens with shared libraries? Do Xlib and Motif > support the byte remapping? Do you need TWO sets of shared > libraries? You would need two sets of any libraries. The whole point, if there was one, would be to support an existing environment that was the reverse of the native endian. > This all sounds fairly ugly to me. The hardware support is > trivial, and it looks good on the spec sheet, but is it > useful in the real world? While running user programs of both endian-ness sounds like (and would be) lots of hard work, it is a *whole* lot easier to do this with the 'RE' bit than without it. MIPS designs processors that hopefully lots of people will use. We try to make them as easy to use as possible. As I said before adding this feature basically just makes the features built into the CPU more fully available to the OS. And on the same topic from another poster: > >From: aglew@crhc.uiuc.edu (Andy Glew) > > In case it isn't obvious - I'd expect that the kernel's > "read/write-from-user space" instructions take into account the RE > bit. Not at all. There is no "read/write-from-user space" instruction. Kernel and user spaces are distinct, much like the VAX. If the upper bit is on, the address is kernel space. If the upper bit is off, the address is a user address. The "current user address space" is defined by a couple of registers -- an Address Space Identifier (for the TLB cache), and something that works out to be a PTE base pointer in kernel virtual space. Copies from/to the "current user address space" are just loads and stores that get translated using the current values in the registers. In the case under discussion, loads/stores to a reverse endian user process address space, the loads and store happen to the word-oriented memory system in the kernel-mode environment; i.e. using the native byte order established at chip reset time. That means that everything is backwards... with words reversed (or is that "kcabdraw...s"?) If this was a new hardware feature, no doubt it would work differently, but it just something to enable the load-aligner network in either mode. -- Charlie Price cprice@mips.mips.com (408) 720-1700 MIPS Computer Systems / 928 Arques Ave. / Sunnyvale, CA 94086-23650