sritacco@hpdmd48.boi.hp.com (Steve Ritacco) (10/26/90)
As I understand it, the Mips R3000A has been released. Would someone mind explaining the "dynamic byte swapping" feature?
mash@mips.COM (John Mashey) (10/30/90)
In article <14900018@hpdmd48.boi.hp.com> sritacco@hpdmd48.boi.hp.com (Steve Ritacco) writes: >As I understand it, the Mips R3000A has been released. >Would someone mind explaining the "dynamic byte swapping" feature? In R2000s and R3000s, when you reset the CPU, you choose at that time which byte-order is to be used, and it doesn't change without another reset. It is possible (and has been done), to use external circuits, plus software, to have a "soft reset" that can flip the whole machine. 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. There is, of course, a way to distinguish Big-Endian binaries from Little-Endian ones (magic number), and hence, the hardware is there to let a single machine run a mixture of such binaries, i.e., the byte order is selected on a process-by-process basis. (Note that this is NOT a product announcement, or commitment that anyone is going to do the software work ("a minor matter of software" :-) just a note that the hardware now permits this in a sensible fashion.) -- -john mashey DISCLAIMER: <generic disclaimer, I speak for me only, etc> UUCP: mash@mips.com OR {ames,decwrl,prls,pyramid}!mips!mash DDD: 408-524-7015, 524-8253 or (main number) 408-720-1700 USPS: MIPS Computer Systems, 930 E. Arques, Sunnyvale, CA 94086
lewine@dg-rtp.dg.com (Donald Lewine) (10/30/90)
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. 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. 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? Also, what happens with shared libraries? Do Xlib and Motif support the byte remapping? Do you need TWO sets of shared libraries? 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? -------------------------------------------------------------------- Donald A. Lewine (508) 870-9008 Voice Data General Corporation (508) 366-0750 FAX 4400 Computer Drive. MS D112A Westboro, MA 01580 U.S.A. uucp: uunet!dg!lewine Internet: lewine@cheshirecat.webo.dg.com
aglew@crhc.uiuc.edu (Andy Glew) (11/01/90)
..> R6000s and R3000As with a "reverse endian" status bit for dynamic byte swapping... I'd almost venture that the RE bit should be per-page - except that that would louse up caches (you wouldn't know how to set up the controls for the byte swap logic until the data had been fetched from cache). -- Andy Glew, a-glew@uiuc.edu [get ph nameserver from uxc.cso.uiuc.edu:net/qi]
aglew@crhc.uiuc.edu (Andy Glew) (11/06/90)
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. -- Andy Glew, a-glew@uiuc.edu [get ph nameserver from uxc.cso.uiuc.edu:net/qi]
cprice@mips.COM (Charlie Price) (11/09/90)
> >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
zs01+@andrew.cmu.edu (Zalman Stern) (11/17/90)
[lewine@dg-rtp.dg.com (Donald Lewine) asks] > Also, what happens with shared libraries? Do Xlib and Motif > support the byte remapping? Do you need TWO sets of shared > libraries? Xlib and Motif already have code to deal with either byte order since the X server may be on a machine of different byte-gender than the client. (Actually, some of the code may be in the server instead. Either way, one of the two programs does the conversion.) Byte-order tolerance is simply part of writing portable code these days. Fortunately, packages like XDR make this easier. It should also be noted that both the Motorola 88k and AMD 29000 have byte-order bits in their status registers. Zalman Stern, MIPS Computer Systems, 930 E. Arques, Sunnyvale, CA 94086 zalman@mips.com OR {ames,decwrl,prls,pyramid}!mips!zalman