Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!mips!cprice From: cprice@mips.com (Charlie Price) Newsgroups: comp.sys.mips Subject: Re: ACE - Big or Little Endian Keywords: ACE Message-ID: <4861@spim.mips.COM> Date: 18 Jun 91 23:12:22 GMT References: Sender: news@mips.COM Organization: MIPS Computer Systems, Inc Lines: 58 Nntp-Posting-Host: lloyd.mips.com In article k2@bl.physik.tu-muenchen.de (Klaus Steinberger) writes: >I've heard from some source on the net, and from our local DEC rep, that >the ACE initiave has defined their machines to LITTLE ENDIAN. > >Because MIPS and CDC are members of ACE, i'm interested, in their >strategy regarding BIG/LITTLE Endian. We have now a CD4680 (RC6280) >and two CD4330 (RC3230). Will we run into trouble, if we want to buy >additional systems in the near/far future? Or they are doing some magic stuff >to run both worlds? (with MIPS-II it's possible?) > >Klaus Steinberger Yes, the ARC spec from ACE does specify little endian hardware. My *opinion* is that neither MIPS nor CDC (nor any of our other OEMs) has any attention of stranding people who have shown the good judgement to buy systems from us. We want to continue to ship systems to happy customers! Disclaimer: The following is not an official description of MIPS product plan -- I don't do that. It is a description of a possible solution to endian compatibility issues. * current MIPS processors (R3000A, R6000, someday-a-product R4000) can switch the endian operation of user mode on the fly. * with an engine like that, it is possible, with some OS work, to run processes of non-native endianness. * In such a bi-endian system text files (character data) would be transparently shared among mixed-endian processes. To make that happen, the OS does some transformation on all the I/O data to/from non-native endian processes (moving characters around -- on an ascii system it would swap bytes in a memory word). * the CPU cost of I/O data transformation isn't excessive -- a few percent of the CPU for reasonable I/O loads. It is certainly feasible not to care about this CPU cost. * sharing arbitrary binary data among same-endian processes whether native or non-native works, just like always. Sharing arbitary binary data between different-endian processes doesn't work transparently -- just like it doesn't on mixed-endian network filesystems. * This sort of arrangement would allow a user to run either existing big-endian binaries on a little-endian ARC-compliant machine with a bi-endian OS or ACE-inspired shrink-wrapped little-endian software on a big-endian machine. * there are other issues that I haven't touched on, but it is clearly feasible to provide usable bi-endian environments. -- Charlie Price cprice@mips.mips.com (408) 720-1700 MIPS Computer Systems / 928 Arques Ave. MS 1-03 / Sunnyvale, CA 94088-3650