dillon@POSTGRES.BERKELEY.EDU (Matt Dillon) (05/14/89)
One other easily integratable future item that would result from using files for VM paging (and this is definitely in the future!) would be, just as in the UNIX mmap(2) call, the ability to access a file which is mapped into memory and have Read/Write calls on that file get data from memory (for mapped portions) or disk (unmapped or paged out portions) transparently. That is, r/w calls return the most up to date information. This would allow almost painless implementation of something similar to Apple's 7.0 hot links. Not only do programs have a choice of access method... map the file into VM and/or access it with Read()/Write() calls, but it would put all the (possibly huge) associated data into VM allowing for almost arbitrarily large amounts of shared data. Frankly, the only thing holding me back from using the clipboard now is the memory limitation. -Matt
papa@pollux.usc.edu (Marco Papa) (05/14/89)
One of the positive effects of the Apple propaganda of System 7.0 seems to have been the conclusion that Virtual Memory would be a very nice addition to AmigaDOS and it might not be TOO difficult to add to a future version of the Amiga system software. I am claiming that 1.4 SHOULD include support for VM. If possible, I would suggest that one of the V1.4 sessions at the June DevCon include a discussion on "VM & 1.4" (of course if Dave Haynie doesn't show up with VM-SetCPU :-) Andy? Lauren? -- Marco Papa 'Doc' -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= uucp:...!pollux!papa BIX:papa ARPAnet:pollux!papa@oberon.usc.edu "There's Alpha, Beta, Gamma and Diga!" -- Leo Schwab [quoting Rick Unland] -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
elg@killer.Dallas.TX.US (Eric Green) (05/15/89)
in article <17209@usc.edu>, papa@pollux.usc.edu (Marco Papa) says: > AmigaDOS and it might not be TOO difficult to add to a future version of the > Amiga system software. I am claiming that 1.4 SHOULD include support for VM. > If possible, I would suggest that one of the V1.4 sessions at the June DevCon > include a discussion on "VM & 1.4" (of course if Dave Haynie doesn't show up > with VM-SetCPU :-) Andy? Lauren? Well, Marco, I agree that a future version of AmigaDOS should include support for VM. But I rather think it'll make it into 1.5 rather than 1.4. 1.4 should be fairly well along right now, only a few months away from the point of throwing to QA (into which it'll disappear for six months, of course). Delaying the release of 1.4 (and all its advantages -- a real Workbench, improved FFS, re-written DOS, etc.) just for the benefit of a few people who have A2620 boards seems pretty ridiculous to me. On the other hand, I do agree that one of the V1.4 sessions at June DevCon should deal with "VM & AmigaDOS". The standards for future VM processing should be decided on, and should be explicitly stated in the 1.4 "Bible" so that when 1.5 comes out things can transition as easily as possible. -- | // Eric Lee Green P.O. Box 92191, Lafayette, LA 70509 | | // ..!{ames,decwrl,mit-eddie,osu-cis}!killer!elg (318)989-9849 | | // Join the Church of HAL, and worship at the altar of all computers | |\X/ with three-letter names (e.g. IBM and DEC). White lab coats optional.|
wayneck@tekig5.PEN.TEK.COM (Wayne Knapp) (05/16/89)
In article <17209@usc.edu>, papa@pollux.usc.edu (Marco Papa) writes: > One of the positive effects of the Apple propaganda of System 7.0 seems to > have been the conclusion that Virtual Memory would be a very nice addition to > AmigaDOS and it might not be TOO difficult to add to a future version of the > Amiga system software. I am claiming that 1.4 SHOULD include support for VM. > If possible, I would suggest that one of the V1.4 sessions at the June DevCon > include a discussion on "VM & 1.4" (of course if Dave Haynie doesn't show up > with VM-SetCPU :-) Andy? Lauren? > > -- Marco Papa 'Doc' Well I don't agree. There is a much more basic problem that should be addressed before virtual memory is added to the Amiga. This is the problem that there are two pools of different memory in the Amiga. VM (virtual memory) won't buy one much more than the ability to run multitasking programs very slowly until you run out of CHIP RAM. The real bottleneck in the Amiga is the CHIP RAM. 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 # ########### # # ####### # # ###################### ####### Now you would have a system that VM could be added to. Programming would be easier and maybe we would see some real improvement in the Amiga. The above changes may require some changes in the custom chips, since some things like the VIEW are global, but maybe not. If the system was smart enough it could use the MMU to map what ever pages RAM needed into the custom chips address space. This way one could even have appications that used multiple megabytes of CHIP ram even though at any one instance the custom chips can only address one megabyte of RAM. Some kind of MapToChips() function and a HoldToChips() function would have to be written, but with today's hardware this shouldn't be too hard. Things like using the blitter to move memory anywhere to anywhere would be possible. Or using almost a whole megabyte of RAM for a graphics display and being able to page flip to another whole display would be easy. The mind would be the only limit on what could be done, since making memory available to the custom chips would only require setting up the MMU. Also the Amiga would be much easier to improve. So what do you all think? Wayne Knapp
c60c-1ea@web-1c.berkeley.edu (Yen Yuanchi Hsieh) (05/16/89)
In article <4182@tekig5.PEN.TEK.COM> wayneck@tekig5.PEN.TEK.COM (Wayne Knapp) writes: >So why not build a system like this: > >Amiga 3000 +===#################### >---------- + # Page control RAM # > + #################### > ########### ####### ###################### ####### > # CUSTOM #====# MMU #====# # ####### # # > # CHIPS # ####### # Single Pool of RAM #=====# MMU #===# CPU # > ########### # # ####### # # > ###################### ####### ^ | Wait States... graphics 'controller' + wait states = bad idea. Just ask any VGA-controller owner. :-) Would be nice, though... > Wayne Knapp David Navas
doug@xdos.UUCP (Doug Merritt) (05/16/89)
In article <24470@agate.BERKELEY.EDU> c60c-1ea@web-1c.berkeley.edu (Yen Yuanchi Hsieh) writes: [ deleted diagram indicating an MMU between the Amiga graphics chips and memory ] >graphics 'controller' + wait states = bad idea. > >Just ask any VGA-controller owner. :-) It is not impossible to design a zero-wait state MMU, especially one that might be special purpose like this (e.g. mostly intended for chip-ram base-address flipping). I think it's probably possible even to do it at a reasonable price. The Amiga's clock rate is pretty slow by today's standards; that makes it easier to conceive ways of slipping in a subsystem that appears practically instantaneous to the rest of the system. Doug -- Doug Merritt {pyramid,apple}!xdos!doug Member, Crusaders for a Better Tomorrow Professional Wildeyed Visionary
wayneck@tekig5.PEN.TEK.COM (Wayne Knapp) (05/17/89)
In article <24470@agate.BERKELEY.EDU>, c60c-1ea@web-1c.berkeley.edu (Yen Yuanchi Hsieh) writes: > In article <4182@tekig5.PEN.TEK.COM> wayneck@tekig5.PEN.TEK.COM (Wayne Knapp) writes: > >So why not build a system like this: > > > >Amiga 3000 +===#################### > >---------- + # Page control RAM # > > + #################### > > ########### ####### ###################### ####### > > # CUSTOM #====# MMU #====# # ####### # # > > # CHIPS # ####### # Single Pool of RAM #=====# MMU #===# CPU # > > ########### # # ####### # # > > ###################### ####### > ^ > | > Wait States... ^^^^^^^^^^^^^ However if built right wait states could be avoided since: 1. Copper only accesses 1 out of 4 memory cycles at best 2. Blitter only accesses 1 out 2 memory cycles at best and it isn't real time anyway. 3. The Playfield DMA can run every cycle in high res. 16 color, but the memory it accesses is in order. 4. Sound and spirtes accesses are needed that often. So you did catch me, but maybe a "smart" MMU could do the job. I was thinking more on the idea of using the MMU as a page controller, controlling which pages of RAM the custom chips could use and wait staing the main CPU when using the same page as a custom chip is working on. The two MMU's would have to have a master/slave relationship where the CPU MMU is the slave. I'm glad to see that someone out there is awake! Wayne Knapp
daveh@cbmvax.UUCP (Dave Haynie) (05/17/89)
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
papa@pollux.usc.edu (Marco Papa) (05/18/89)
In article <4182@tekig5.PEN.TEK.COM| wayneck@tekig5.PEN.TEK.COM (Wayne Knapp) writes: |In article <17209@usc.edu|, papa@pollux.usc.edu (Marco Papa) writes: || Amiga system software. I am claiming that 1.4 SHOULD include support for VM. || If possible, I would suggest that one of the V1.4 sessions at the June DevCon || include a discussion on "VM & 1.4". | |Well I don't agree. There is a much more basic problem that should be |addressed before virtual memory is added to the Amiga. This is the |problem that there are two pools of different memory in the Amiga. [.. details omitted] |Amiga. The above changes may require some changes in the custom |chips, since some things like the VIEW are global, but maybe not. That's the problem with you approach. The ECS is not even out, and it can't be changed in the short term. Virtual Memory could be added with only changes in the software. -- Marco Papa 'Doc' -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= uucp:...!pollux!papa BIX:papa ARPAnet:pollux!papa@oberon.usc.edu "There's Alpha, Beta, Gamma and Diga!" -- Leo Schwab [quoting Rick Unland] -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=