Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!apple!oliveb!amiga!cbmvax!daveh
From: daveh@cbmvax.UUCP (Dave Haynie)
Newsgroups: comp.sys.amiga.tech
Subject: Re: Virtual Memory / doable 1.4 request / Hot links
Message-ID: <6896@cbmvax.UUCP>
Date: 17 May 89 16:44:56 GMT
References: <4182@tekig5.PEN.TEK.COM>
Organization: Commodore Technology, West Chester, PA
Lines: 63

in article <4182@tekig5.PEN.TEK.COM>, wayneck@tekig5.PEN.TEK.COM (Wayne Knapp) says:

> There is a much more basic problem that should be addressed before virtual memory 
> is added to the Amiga [eg, virtual CHIP as well as FAST memory...]

> It is limited in size, speed, and location. So why not build a system like this:

> Amiga 3000         +===####################
> ----------         +   # Page control RAM #
>                    +   #################### 
>  ###########    #######    ######################               ####### 
>  #  CUSTOM #====# MMU #====#                    #     #######   #     #
>  #   CHIPS #    #######    # Single Pool of RAM #=====# MMU #===# CPU #
>  ###########               #                    #     #######   #     # 
>                            ######################               #######

While I think virtual Chip memory is an interesting concept, this scheme
won't work.  First of all, the CPU needs the virtual Chip address; what you
show here gives the CPU physical Chip addresses, or makes the programming
of the Chip MMU cumbersome in that it has to completely track the CPU's
MMU.  That's a sticky problem, in that any Chip page fault handled by the
'030's MMU must immediately be updated in the Chip MMU, and any
blitter/copper induced page fault must be updated in the CPU's MMU.  I
guess the cleanest way this could happen would be for the Chip MMU to read
'030 MMU tables, though I think we're missing a "this is Chip RAM" tag in
the '030 page descriptor, so it would still have to be geographically
managed.  Also, there's no mechanism for ATC consistency in the '030, so
you'd be in deep trouble if the Chip MMU modified a cached translation. 

The other problem is that, depending on the graphics mode, the custom chips
can eat up nearly all available bandwith on the bus they sit on.  I don't
care if it's today's Chips or some magic new ones of tomorrow -- if they
can't take most of the bus time in some graphic mode, you're not being
given a faster chip set, you're being cheated out of some useful mode.  So
as soon as I eliminate the separate memory pools, I cut the system
performance in half.  No way around it, this is a simple parallel to serial
conversion here.  No matter how much faster I make main memory, these days
I've got a CPU that can use most the available main memory bandwidth, a
Chip system that can use most of the available chip memory bandwidth, and
possibly an expansion device that can eat up whatever it can get from the
expansion bus.  Any time a bus crossing is forced, I take a big performance
hit.

There is one solution to this, of course: cache.  For a CPU system with a
decent sized cache, say, 4k-64k, the main memory bandwidth needed can drop
considerably without hurting CPU performance greatly.  Same is in theory
true with the custom chips, but they don't lend themselves well to caching.
In order to build a workable system like this, I suspect we'd need a cache
at least as large as whatever your largest screen is going to be.  The problem
of course being that display fetch is basically linear, and if you use a cache
smaller than the display size, a subsequent line fetch will overrun the cached
lines from previous fetches, and you'll get a cache hit.  So start thinking
of a cache that's about as large as today's 512k of CHIP RAM, and we may be
heading in the right direction.  But for decent performance, it's gotta be a
copyback cache will full hardware consistency, which means the CPU will most
likely have to be a 68040.  Which means this isn't going to happen in the
A3000, if it ever does happen.  Still, a very interesting concept....

>                                        Wayne Knapp 
-- 
Dave Haynie  "The 32 Bit Guy"     Commodore-Amiga  "The Crew That Never Rests"
   {uunet|pyramid|rutgers}!cbmvax!daveh      PLINK: D-DAVE H     BIX: hazy
              Amiga -- It's not just a job, it's an obsession