Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!uunet!uvm-gen!pegram
From: pegram@uvm-gen.UUCP (pegram r)
Newsgroups: comp.arch
Subject: Re: 64-bit addresses & multiprocessor cache request
Message-ID: <1400@uvm-gen.UUCP>
Date: 21 Feb 90 17:12:37 GMT
References: <7971@pt.cs.cmu.edu>
Sender: nobody@uvm-gen.UUCP
Organization: EMBA Computer Facility, Univ. of Vermont, Burlington.
Lines: 32

From article <7971@pt.cs.cmu.edu>, by lindsay@MATHOM.GANDALF.CS.CMU.EDU (Donald Lindsay):
> In article <8840009@hpfcso.HP.COM> dgr@hpfcso.HP.COM (Dave Roberts) writes:
>>All those signals coming out of a chip will take
>>a lot of chip area around the edge of a die, hence driving physical die
>>sizes up (and chip yields down).
 
> The "small" system of the future would map a 48-bit or 64-bit virtual
> address to a 32-bit physical address. With an on-chip MMU, the pin
> count would be the same as it is now.
> -- 
> Don		D.C.Lindsay 	Carnegie Mellon Computer Science

I can possibly see the small system of the future operating that way, but
for really small systems, make the MMU optional, and slow the chip
slightly by multiplexing the data and address lines.  That requires no
more lines than are used currently and lets the external latches
handle the drive problems.

On another subject, does anyone have any recent references on cache
coherency in multiprocessor systems (with a good bibliographies)?  
I have a paper to write and don't want to miss current work.  Since
medium to fine grain multiprocessing systems use micros, I have 
been reading papers about recent microprocessor (cache) designs that 
allow for parallel processing, such as the cache descriptions in 
articles on the 68040.  The bus snooping - write back option of that 
design seems rather crude though, maybe off chip caches can be cleverer.
Email responses would be nice, I will post a summary only if there is 
interest.

Bob Pegram (Internet: pegram@griffin.uvm.edu) 301B, Votey Bldg.
					      University of Vermont
					      Burlington, Vt. 05405