Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!mips!zalman
From: zalman@mips.com (Zalman Stern)
Newsgroups: comp.arch
Subject: Re: bi-endian environments
Message-ID: <3410@spim.mips.COM>
Date: 11 May 91 12:09:16 GMT
References: <168@titccy.cc.titech.ac.jp> <3308@spim.mips.COM> <1991May10.180241.540@oakhill.sps.mot.com>
Sender: news@mips.COM
Distribution: comp
Organization: MIPS Computer Systems, Sunnyvale, California
Lines: 69
Nntp-Posting-Host: dish.mips.com

In article <1991May10.180241.540@oakhill.sps.mot.com> billm@speedy.UUCP (Bill Moyer) writes:
>In article <3308@spim.mips.COM> cprice@mips.com (Charlie Price) writes:
[...]
>>You *can* arrange to share ONE binary format.
>>I think the only reasonable one to pick is characters (i.e. bytes).
>>For data that processes share actively and access it frequently,
>>I suspect that you won't like the performance of mixed endian access,
>>but you can certainly make it *work*.
>>For a non-native process using a mapped file, you ned to do the same
>>transform that you would for any unmapped I/O --
>>When a page is accessed, and mapped to the process,
>>the OS must swap the bytes around within the page so that
>>character-stream order is preserved.
>
>I don't quite understand this. Endianness applies to objects, not pages.
>If I update a data structure consisting of two short ints (16-bit)
>and an int (32-bit) in little endian mode, and then reverse all of the bytes
>of the structure for access by a big-endian process, the two shorts will
>be swapped, which is not the desired effect. I don't think the OS has
>enough knowledge of the size and placement of elements in an arbitrary
>page of data to perform the transformation. What am I missing?

You aren't missing anything. The OS cannot make things transparent.
However, it must provide correct access to byte streams which has always
worked before. Since current bi-endian chips(*) muck with byte (and short,
and maybe word) addresses (as opposed to swapping multi-byte data when
necessary) you have to swap the buffers to get byte stream access to work
right.

>
>It seems to me that an application could run in either endian mode
>if the processor is capable of performing the byte reordering based on
>the size of the object being accessed. This would imply that not swapping
>bytes within a 32-bit word on 32_bit accesses is not the desired action, 
>since once the processor data bus is wired to a given set of byte-lanes
>to memory, access to a 32-bit data type in the opposite endianness, followed
>by a byte reversal ends up producing the wrong result.

Removing the double negative, I think you are trying to say that providing
byte swapping on the data bus works... I agree. But its a big hit to the
hardware and its not worth doing. Note, it still doesn't buy byte order
transparency. If a big endian process does a store word and a little endian
process does a load word it will get a byte reversed value. (In a previous
post I said that on an R3000 they would get the same value, I'm not sure
that is true because I think things are swapped with respect to 64 bit
words so FP loads/stores make sense. On the R3000 they may actually get
completely unrelated values...)

>In addition,
>processors with different size data buses cannot communicate correctly
>because they will make different assumptions about where the byte
>located at address X is accessed. An 8-bit processor which desires
>to read a 32-bit element by performing 4 single byte accesses, and accumulating
>the data will not end up with what the 32-bit processor wrote in the
>opposite endian configuration, even if the software attemps to account for the
>order of storage in memory.

This makes no sense to me.

>Bill Moyer                        insert disclaimer here --> <>
>MC88110 Design
>Motorola Microprocessor Products Group

(*) If anyone knows of a chip that actually does transparent byte swapping
on the byte lanes of the data bus, please let me know.
-- 
Zalman Stern, MIPS Computer Systems, 928 E. Arques 1-03, Sunnyvale, CA 94088
zalman@mips.com OR {ames,decwrl,prls,pyramid}!mips!zalman     (408) 524 8395
  "Never rub another man's rhubarb" -- the Joker via Pop Will Eat Itself