Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!wuarchive!uunet!auspex!guy
From: guy@auspex.auspex.com (Guy Harris)
Newsgroups: comp.unix.internals
Subject: Re: Fundamental defect of the concept of shared libraries
Message-ID: <8063@auspex.auspex.com>
Date: 28 May 91 17:34:12 GMT
References: <216@titccy.cc.titech.ac.jp> <674816585.AA7847@flaccid> <219@titccy.cc.titech.ac.jp>
Organization: Auspex Systems, Santa Clara
Lines: 23

>>	"The mapping of these extended, process-unique virtual addresses to
>>	physical addresses need not be one-to-one; virtual addresses of two
>>	or more different processes may map to the same physical address."
>
>Compared to R4000, R2000/R3000 are slower CPUs.

So what?  Are you saying that the virtually indexed, physically tagged
cache on the R4000, *unlike* the virtually indexed, physically tagged
cache on the R3000, is unable to support having different virtual
addresses mapped to the same physical address?  (It's already been
demonstrated, by the quote above, that your previous categorical assertions
that a virtually indexed, physically tagged cache *can't* support
different virtual addresses mapped to the same physical address is
completely and utterly untrue.)

If you're asserting that, you'd better offer some evidence; I doubt
anybody in the audience is going to take your word for it.  Given that
MIPS presumably has the intention of preserving compatibility between
earlier R-series chips and the R4000, including the same ability to
support OS features such as "mmap()" and shareable libraries (present
both in S5R4 and OSF/1), the burden of proof is *entirely* upon *you* to
demonstrate that it *can't* support it - and to demonstrate so by citing
statements from MIPS that it can't, not by waving your hands.