Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!sdd.hp.com!news.cs.indiana.edu!rutgers!cbmvax!daveh From: daveh@cbmvax.commodore.com (Dave Haynie) Newsgroups: comp.sys.amiga.hardware Subject: Re: 68030 options. Message-ID: <20156@cbmvax.commodore.com> Date: 27 Mar 91 13:59:01 GMT References: <47678@nigel.ee.udel.edu> <19944@cbmvax.commodore.com> <1991Mar26.095729.29291@kuhub.cc.ukans.edu> Reply-To: daveh@cbmvax.commodore.com (Dave Haynie) Organization: Commodore, West Chester, PA Lines: 52 In article <1991Mar26.095729.29291@kuhub.cc.ukans.edu> markv@kuhub.cc.ukans.edu writes: >A query and a request? One thing I havn't seen mentioned is the >68040's MMU's ability to monitor the bus, and update its caches on >accesses to cached RAM, and to inhibit RAM and supply a valued for a >cached address that hasn't been "written thru". This would eliminate >the cache coherency problem and avoid the severe performance hit your >going to take if you have to flush 4K of cache on *every* DMA I/O >(unless there's some more intellegence in the process). >My questions are, does the 3000's CPU slot have the signals available >that would let it do this for motherboard RAM, or would it be >restricted do any "on-board" RAM. It's probably possible. The A3000's Coprocessor slot supports a signal that allows a Coprocessor device to intercept an address intended for either onboard Fast RAM or for expansion space. So, in theory, a 68040 or other bus snooping device could monitor system addresses and respond with its own data, rather than the data in that particular location. Extra logic would be required on the Coprocessor card, of course; I'm not implying that the A3000 Coprocessor slot implements the 68040 bus snooping protocol, only that it's possible to map some bus snooping protocol onto the signals there, with extra logic. The main intention of that signal (called WAIT*) is to allow "bus-attached" cache devices. In most cache systems, the cache kind of sits between the processor and the rest of the world. You can add a cache to the Coprocessor slot on the A3000, however, obviously without inserting it between the on-board CPU and the rest of the motherboard. This is done by using the WAIT* signal. The CPU sends out its address, which is examined by the cache device, holding WAIT* true. If the address isn't cached, the device releases WAIT* and the normal memory device responds. If it is, the cache supplies the data and terminates the cycle. >Otherwise, what about a few more OS extensions that expliot the PMMU >to inhibit cacheing of regions used for DMA buffers (this of course is >in the direction of my dream of OS support for the MMU in general, >maybe some flags like MEMF_NOCACHE and MEMF_NOPAGE, locking blocks, etc). Good ideas they are. The current OS suggests a cache flush after a DMA operation, which works, but if you guarantee a specific chunk of memory would be uncachable during such a transfer, you'd be more efficient. Of course, the bus-attached cache I described above doesn't need to be cleared after a DMA, since it monitors all bus activity, and can cache DMAC cycles just as easily as CPU cycles if you let it. >Mark Gooderum Only... \ Good Cheer !!! -- Dave Haynie Commodore-Amiga (Amiga 3000) "The Crew That Never Rests" {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: hazy BIX: hazy "That's me in the corner, that's me in the spotlight" -R.E.M.