🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.arch
Article #11456

Re: bi-endian environments

#11456
From: Stephen P Spackman
Date: Fri, 10 May 1991 06:22
53 lines
3065 bytes
In article <3308@spim.mips.COM> cprice@mips.com (Charlie Price) writes:
|You cannot share *arbitrary* binary data transparently through
|either shared memory or the filesystem.

It is in principle possible (read: given a next generation operating
system with its own systems language it will work just fine) to come
VERY close to this, by relying on marshalling code generated from the
type declarations (see my thesis if I ever finish writing it... but
it's a common theme in the newer garbage collection literature).

|You *can* arrange to share ONE binary format.
|I think the only reasonable one to pick is characters (i.e. bytes).

This is a very unfortunate comment. Around HERE, at least, a
"character" is a 16-bit Unichar. Don't let Unix lock in your brain!
:-).

[...description of how you can maintain virtual byte order by
intercepting page mapping...]

|This in-memory page is now in a special state and it has to be
|transformed back to the native character-stream order before it
|can be written back to disk.

You can also sometimes compress at the same time and get back the
performance you lost. (Damn. This comes from the same chap as the
cardmarking generational things. Nice fellow. Here in Chicago
somewhere. Forget his name completely. Damn).

|If a memory-mapped file page or shared memory segment page is accessed
|by processes that have different endian-ness, the page has to be put into
|the proper character-stream order before the access can be granted.

But note that you DON'T HAVE to transform before write-back, not if
the page can be marked with its PRESENT format! :-)

|This would be very expensive for highly-shared accesses,
|so I suspect people won't do it very much.

Not as bad as you might think. Consider dynamically recompiling some
of the IO code and sticking it into the user's address space....

|Fortunately, most file access, mapped or otherwise, doesn't involve
|a high degree of simultaneous access by several processes.

Sometimes. But this isn't always going to be true in an OO world....

It's time to get serious about the place where hardware and software
meet....
----------------------------------------------------------------------
stephen p spackman         Center for Information and Language Studies
systems analyst                                  University of Chicago
----------------------------------------------------------------------
Technical Details
Message-ID: <STEPHEN.91May10002243@estragon.uchicago.edu>
Path: arc1-ca.pugleaf.net!utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!midway!midway!stephen
References: <159@titccy.cc.titech.ac.jp> <3225@spim.mips.COM> <168@titccy.cc.titech.ac.jp> <3308@spim.mips.COM>

Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!midway!midway!stephen
From: stephen@estragon.uchicago.edu (Stephen P Spackman)
Newsgroups: comp.arch
Subject: Re: bi-endian environments
Message-ID: <STEPHEN.91May10002243@estragon.uchicago.edu>
Date: 10 May 91 06:22:43 GMT
References: <159@titccy.cc.titech.ac.jp> <3225@spim.mips.COM>
 <168@titccy.cc.titech.ac.jp> <3308@spim.mips.COM>
Sender: news@midway.uchicago.edu (NewsMistress)
Distribution: comp
Organization: University of Chicago CILS
Lines: 53
In-Reply-To: cprice@mips.com's message of 9 May 91 20: 46:25 GMT