Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!dg!dg-rtp.dg.com!lewine
From: lewine@dg-rtp.dg.com (Donald Lewine)
Newsgroups: comp.arch
Subject: Re: R3000A question ???
Message-ID: <1092@dg.dg.com>
Date: 30 Oct 90 14:45:29 GMT
References: <14900018@hpdmd48.boi.hp.com> <42474@mips.mips.COM>
Sender: root@dg.dg.com
Reply-To: uunet!dg!lewine
Organization: Data General Corporation
Lines: 35

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