Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!oakhill!billm
From: billm@oakhill.sps.mot.com (Bill Moyer)
Newsgroups: comp.arch
Subject: Re: bi-endian environments
Message-ID: <1991May10.180241.540@oakhill.sps.mot.com>
Date: 10 May 91 18:02:41 GMT
References: <159@titccy.cc.titech.ac.jp> <3225@spim.mips.COM> <168@titccy.cc.titech.ac.jp> <3308@spim.mips.COM>
Reply-To: billm@speedy.UUCP (Bill Moyer)
Distribution: comp
Organization: Motorola Inc., Austin, Texas
Lines: 65

In article <3308@spim.mips.COM> cprice@mips.com (Charlie Price) writes:
>I don't especially want to get into this discussion in deep technical
>detail (partly because I probably don't *understand* deep detail),
>but I don't want to let these conclusions stand without qualification.

I know I'm asking for it, but........

>
>In article <168@titccy.cc.titech.ac.jp> mohta@necom830.cc.titech.ac.jp (Masataka Ohta) writes:
>>In article <3225@spim.mips.COM> cprice@mips.com (Charlie Price) writes:
>
>... how the R4000 implements endian-ness...
>
>>Then, shared memory between processes of different endian is impossible.
>>
>>This means that access to a file through memory mapping mechanism is
>>impossible, if the file is accessed from processes of different endian.
>
>You cannot share *arbitrary* binary data transparently through
>either shared memory or the filesystem.
>
>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?

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. 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.

Thoughts ?
>
>-- 
>Charlie Price    cprice@mips.mips.com        (408) 720-1700
>MIPS Computer Systems / 928 Arques Ave.  MS 1-03 / Sunnyvale, CA   94088-3650


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