gnb@melba.bby.oz (Gregory N. Bond) (01/17/89)
With regard to DEC using the MIPS chip in little-endian mode:
Is it reasonably simple to provide a binary translator to change
a big-endian binary to a little-endian binary? Could you then
easily recognise system calls and convert them?
In short, convert DEC/Ultrix/little-endian to MIPSCO/sysV/big-endian?
After all, the compilers & machine code are the same...
Greg.
--
Gregory Bond, Burdett Buckeridge & Young Ltd, Melbourne, Australia
Internet: gnb@melba.bby.oz.au non-MX: gnb%melba.bby.oz@uunet.uu.net
Uucp: {uunet,mnetor,pyramid,ubc-vision,ukc,mcvax,...}!munnari!melba.bby.oz!gnbzs01+@andrew.cmu.edu (Zalman Stern) (01/23/89)
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
tim@crackle.amd.com (Tim Olson) (01/23/89)
In article <76@melba.oz> gnb@melba.bby.oz.au writes: | With regard to DEC using the MIPS chip in little-endian mode: | | Is it reasonably simple to provide a binary translator to change | a big-endian binary to a little-endian binary? Could you then | easily recognise system calls and convert them? This is difficult unless you know the "natural sizes" of all of the data items. For example, if you want to convert data from big-endian to little-endian, you must swap bytes within half-words, and swap half-words within words, but you don't do anything to byte-sized data (strings, as well). If you have an unstripped binary with debug information, then you can derive the data sizes from it, but it is probably not possible with stripped binaries. -- Tim Olson Advanced Micro Devices (tim@crackle.amd.com)
vixie@decwrl.dec.com (Paul A Vixie) (01/23/89)
[Bond] # In short, convert DEC/Ultrix/little-endian to MIPSCO/sysV/big-endian? # # After all, the compilers & machine code are the same... Sounds like a good idea at first, but then you realize that all the syscall vector assignments are probably different. Maybe not all, but some. This is part of what an ABI would have specified. It's basically not worth the trouble of translating -- the little-end-MIPS and the big-end-MIPS should be thought of as distinct architectures (each with its place!) that have the same (fantastic!) compiler technology. -- Paul Vixie Work: vixie@decwrl.dec.com decwrl!vixie +1 415 853 6600 Play: paul@vixie.sf.ca.us vixie!paul +1 415 864 7013
w-colinp@microsoft.UUCP (Colin Plumb) (01/23/89)
zs01+@andrew.cmu.edu (Zalman Stern) wrote: > 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... The 29000 has a bit in the configuration register. This isn't intended to be set more than once between resets, but I don't see anything stopping you from making it per-process context. Also, the 29000 has insert/extract byte and halfword instructions; it's these the byte sex bit modifies. Basically, it involves xoring the low two bits if the address with 11 (bytes) or 10 (words) if the sex isn't what's expected. If your machine silently ignores unaligned addresses, xor with 11 all the time. -- -Colin (uunet!microsof!w-colinp)