k2@bl.physik.tu-muenchen.de (Klaus Steinberger) (06/18/91)
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?) Sincerely, Klaus Steinberger -- Klaus Steinberger Beschleunigerlabor der TU und LMU Muenchen Phone: (+49 89)3209 4287 Hochschulgelaende FAX: (+49 89)3209 4280 D-8046 Garching, Germany BITNET: K2@DGABLG5P Internet: k2@bl.physik.tu-muenchen.de
cprice@mips.com (Charlie Price) (06/19/91)
In article <k2.677257101@woodstock> 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