Path: utzoo!attcan!uunet!husc6!rutgers!rochester!pt.cs.cmu.edu!andrew.cmu.edu!zs01+ From: zs01+@andrew.cmu.edu (Zalman Stern) Newsgroups: comp.arch Subject: Re: Rx000 byteorder Message-ID: Date: 22 Jan 89 22:26:36 GMT References: <76@melba.oz> Organization: Carnegie Mellon, Pittsburgh, PA Lines: 30 In-Reply-To: <76@melba.oz> I assume the R2000/R3000 have a pin that determines which byte order the system is going to use. Is this correct? When exatly is this pin active? Only at reset time? Which bit patterns does this affect coming into the chip? Just data on loads and stores? Constants in instructions? The instruction opcode bit patterns? If I rember correctly, the AMD 29000 looks at its byte order pin at reset time and the setting thereof only affects load/store operations. I assume this is implemented with some sort of switchable permutation circuit on the D bus... Some of our distributed filesystem people were BS'ing about this and the idea of making byte order a context dependent option in the OS came up. That is, each process would be tagged with its byte order and switching contexts would result in the hardware switching byte order. I know MIPS has different magic numbers in their a.out files for big endian and little endian executables so the kernel could decide at exec time which byte order to use. The only real use I could see for this is emulating Intel architecture in an environment where you have to be big endian for UNIX stuff. I doubt it is even very much of a win there though. It was fun thinking about "byte order independent" trap handlers and the like. Also, with respect to porting DECNET on Ultrix: How do you convert a little endian number to big endian on a big endian machine with BSD UNIX? You can't do it with ntohl or htonl because these are both NULL macros... Sincerely, Zalman Stern Internet: zs01+@andrew.cmu.edu Usenet: I'm soooo confused... Information Technology Center, Carnegie Mellon, Pittsburgh, PA 15213-3890