Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!think.com!sdd.hp.com!mips!cprice From: cprice@mips.com (Charlie Price) Newsgroups: comp.arch Subject: Re: ACE (Was Re: Will NeXT survive? Grow with the times?) Message-ID: <3225@spim.mips.COM> Date: 8 May 91 20:23:00 GMT References: <21199@cbmvax.commodore.com> <3005@spim.mips.COM> <159@titccy.cc.titech.ac.jp> Sender: news@mips.COM Distribution: comp Organization: MIPS Computer Systems, Inc Lines: 73 Nntp-Posting-Host: lloyd.mips.com In article <159@titccy.cc.titech.ac.jp> mohta@necom830.cc.titech.ac.jp (Masataka Ohta) writes: >In article <3005@spim.mips.COM> mash@mips.com (John Mashey) writes: > >>All current MIPS chips can flip byte order dynamically. ARC-compliant >>machines (i.e., those able to run shrink-wrapped operating systems >>of ODT and NT) run native little-endian. MIPS, and others, may well >>build machines that can run that, as well as OS variants that support both >>the existing MIPS binaries, and the ODT binaries [this is quite feasible, >>and in fact, not particularly worse than running both BSD and SV and POSIX >>binaries, as we do right now.] > >I don't think it so easy. > >With the byte order flipping mechanism of R3000, memory, bus and IO is >considered to have the same byte sex with the CPU. > >Thus, it is impossible to share memory (of byte stream) between binaries >with different endian. So, shared memory between them is impossible. >Moreover, because buffer cache (and OS in general) must have some byte >sex, there are difficulties in IO with binaries of the opposite byte sex. > >Are there any workaround, or dose R4000 have different mechanism for >byte flipping? The R4000 does the same sort of thing as the R3000A and the R6000. The *only* time the endian-ness of the processor is relevant is when a partial word (byte, half-word, triple) load or store is performed. The processor uses the endian setting to decide which byte(s) to select from the word or double-word wide cache/memory bus. There is no way (that I know of) to *transparently* share *arbitrary* binary data between big and little endian universes. In the general case, you have to know what the format of the data is and how it was written to know how to read it from the other endian view. If you make a system execute both big and little endian binaries, you get to make one type of binary data share transparently between the universes. To do this, the OS keeps track of the endian-ness of the source/destination of data and does a transform during I/O for non-native sources/destinations. Data is always stored in the native byte order of the machine. The only reasonable choice is to make character streams work correctly. If a program is not the native endianess, the OS flips the bytes in a word end-for-end on transfers to/from the kernel. A non-native text editor can create a text file that the native cat program can display. The cost of doing the data transform for all I/O is not prohibitive. Supporting non-native endianness is clearly a compatibility measure and not the normal way to do business. It is useful in a couple ways: 1) To support programs from both the RISC/os (MIPS Computer Sys), and SVR4 big-endian worlds and the Ultrix (DEC) and the SCO (current and forthcoming OS) little-endian worlds. Presumably as time goes by, machines based on the chip will all become one endian (probably little) and one endianness will dominate in the world of binaries. The fringe applications will convert. 2) To support programs that manipulate data produced in a particular endian format or programs that expect to be run on a particular endian machine. If you have a big-endian compile mode on your little-endian ARC-compliant box, it might be easier to get a big 680x0 or SPARC specific C application running quickly. How well this will work in practice isn't clear to me right now. The problems and confusion may exceed any positive value. -- Charlie Price cprice@mips.mips.com (408) 720-1700 MIPS Computer Systems / 928 Arques Ave. MS 1-03 / Sunnyvale, CA 94086-23650