iddos%TAURUS.BITNET@cunyvm.cuny.edu (06/05/89)
From: iddos%TAURUS.BITNET@cunyvm.cuny.edu Followup-To: comp.sys.amiga , comp.sys.ibm.pc In article <May.17.21.33.39.1989.14040@pilot.njin.net> hubey@pilot.njin.net (Hub >In the last issue of Sentry (I don't have it with me), the GVP board >with a MC68030 and MC 68882 running at 33 MHz (I think) says that >the A2000 gets over 11,000 Dhrystones. Is that good ?? :-). >I think in the same issue the Sun 3/80 registers around 11,000..... In Sentry the Sun 3/80 is quoted as doing 5,150. It is the Sun 3/470 with a $40,900 price tag that does 11,748. The GVP board reaches that with a 32MHz crystal - but is supplied with a 25MHz one. Using a 32MHz crystal caused the CPU to heat up. BTW, the most astonishing fact in this review was that a Compaq 386/20 with a 80386/20NHz + 80387 (does 5,705) costs --$21,421--. Note the <1> (one) dollar. "Err, sorry sir, that was 21,420 plus, lets see, umm, ONE DOLLAR". Ido (The Id) Amin iddos@math.tau.acc.IL.BITNET - or simply iddos@taurus.BITNET
jeh@elmgate.UUCP (Ed J Hanway CUST) (06/07/89)
The GVP 68030 board really looks great (expensive, but great). But nowhere do the reviewers mention whether the 32-bit memory can accept 16-bit DMA (i.e. from a 2090A or HardFrame or other "high-performance" hard disk controller). Does anyone have any information on this? I think I'd take a real performance hit if I had to set my HardFrame up to DMA into chip memory. (Not that it's really THAT slow, but compared to 80ns 32 bit nibble mode RAM, it might as well be core.) P.S. I haven't seen any responses to my earlier posts. Please let me know if you don't see this. 8-) -- Ed Hanway Eastman Kodak Company ...!rochester!kodak!elmgate!jeh
lphillips@lpami.wimsey.bc.ca (Larry Phillips) (06/08/89)
In <1090@elmgate.UUCP>, jeh@elmgate.UUCP (Ed J Hanway CUST) writes: >The GVP 68030 board really looks great (expensive, but great). But nowhere do >the reviewers mention whether the 32-bit memory can accept 16-bit DMA (i.e. >from a 2090A or HardFrame or other "high-performance" hard disk controller). >Does anyone have any information on this? I think I'd take a real performance >hit if I had to set my HardFrame up to DMA into chip memory. (Not that it's >really THAT slow, but compared to 80ns 32 bit nibble mode RAM, it might as >well be core.) According to someone in the 'engineering department' at GVP, you can indeed do 16 bit DMA into their 32 bit ram, but they do not recommend it. The problem is that the 68030 has a data cache as well as an instruction cache. If it has something in its cache, and that same data is modified by an external DMA transfer, the cache will no longer reflect the real value of the data. There are only two choices here, one being to disable the cache (I don't know if you can disable data cache separately from instruction cache), and the other is to use a 'Mask = ' entry in the mountlist to limit DMA to the 16 bit memory. GVP claims that it is better to do the latter, since the 68030 is fast enough to make the programmed IO transfer speeds go very quickly. -larry -- Van Roy's Law: An unbreakable toy is useful for breaking other toys. +----------------------------------------------------------------------+ | // Larry Phillips | | \X/ lphillips@lpami.wimsey.bc.ca or uunet!van-bc!lpami!lphillips | | COMPUSERVE: 76703,4322 | +----------------------------------------------------------------------+
daveh@cbmvax.UUCP (Dave Haynie) (06/09/89)
in article <2461@van-bc.UUCP>, lphillips@lpami.wimsey.bc.ca (Larry Phillips) says: > There are only two choices here, one being to disable the cache (I don't know > if you can disable data cache separately from instruction cache), You sure can. In fact, the OS doesn't turn on the data cache when you power up on an '030 based Amiga, it not knowing the difference between '020 and '030. You need something like SetCPU (which is supplied by GVP, and also recently posted to listings). The third choice, of course, is to use a device driver that knows about '030s and flushes the data cache after a DMA transfer. > and the other is to use a 'Mask = ' entry in the mountlist to limit DMA to > the 16 bit memory. Actually, that means limiting DMA to CHIP memory, which can't be data cached anyway. > GVP claims that it is better to do the latter, since the 68030 is fast > enough to make the programmed IO transfer speeds go very quickly. DMA into CHIP memory is a very losing proposition. The data cache is your choice. I'd recommend keeping it off in a DMA system until you get a device driver that definitely supports cache flushing. Programmed I/O with an '030 isn't much slower than DMA if it's over the bus, and if it's on a magic 32 bit bus like GVP's on-card controller, it's probably about as fast as 16 bit DMA currently is. Note that, chances are, you'll get away with DMA and the data cache MOST of the time. Of course, Murphy will tell you the times you won't.... > -larry -- 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
jwl@Feanor.Stanford.EDU (John Lockhart) (06/09/89)
In article <7069@cbmvax.UUCP> daveh@cbmvax.UUCP (Dave Haynie) writes: >DMA into CHIP memory is a very losing proposition. The data cache is your >choice. I'd recommend keeping it off in a DMA system until you get a >device driver that definitely supports cache flushing. Programmed I/O >with an '030 isn't much slower than DMA if it's over the bus, and if it's >on a magic 32 bit bus like GVP's on-card controller, it's probably about as >fast as 16 bit DMA currently is. > >Note that, chances are, you'll get away with DMA and the data cache MOST of >the time. Of course, Murphy will tell you the times you won't.... >Dave Haynie "The 32 Bit Guy" Commodore-Amiga "The Crew That Never Rests" Um, Dave, I have a CBM A2090 with two ST506 hard drives. I'm also interested in putting a GVP '030 or CBM A2630 on my system to improve performance. Do you know when Commodore will be revising the 2090 driver to deal with the 68030 cache? Or, :-(, should I wait for the Amiga 3000? [I'll probably get one eventually anyway... What will the 3000 have for specs?] -- John ------------------------------------------------------------------------------- -- John Lockhart jwl@feanor.stanford.edu BIX: jlockhart
dbk@teroach.UUCP (Dave Kinzer) (06/09/89)
In article <2461@van-bc.UUCP> lphillips@lpami.wimsey.bc.ca (Larry Phillips) writes: >There are only two choices here, one being to disable the cache (I don't know >if you can disable data cache separately from instruction cache), and the It is and you can. >other is to use a 'Mask = ' entry in the mountlist to limit DMA to the 16 bit >memory. GVP claims that it is better to do the latter, since the 68030 is fast >enough to make the programmed IO transfer speeds go very quickly. >-larry >+----------------------------------------------------------------------+ >| // Larry Phillips | >| \X/ lphillips@lpami.wimsey.bc.ca or uunet!van-bc!lpami!lphillips | >| COMPUSERVE: 76703,4322 | >+----------------------------------------------------------------------+ Unfortunately, I have been known to load a program or two in my usage of my Amiga. If the program is transfered using DMA, there is a possibility of stale data in the instruction cache. The 68030 cache is not exactly a Most Recently Used cache, some stale data can exist even after thousands of instructions have been executed (though not likely [read infrequent guru]). I seem to recall a flush cache system call, but I could not find it in about 2 minutes of looking. If it does not exist, it needs to (can you say 1.4 wish? I knew you could.) It perhaps should be implemented as something external to the system (Romtags?), so as new processors become available it can be easily changed (Also changable for aftermarket cache boards should they become available.) Any task that is in control of DMA (say, the trackdisk device) would call this routine after the DMA is finished. The routine would flush the cache if it exists. | // GOATS - Gladly Offering All Their Support Dave Kinzer (602)897-3085| | // >> In Hell you need 4Mb to Multitask! << uunet!mcdphx!teroach!dbk | | \X/ #define policy_maker(name) (name->salary > 3 * dave.salary) |
daveh@cbmvax.UUCP (Dave Haynie) (06/12/89)
in article <9831@polya.Stanford.EDU>, jwl@Feanor.Stanford.EDU (John Lockhart) says: > Keywords: A2090, hard drive, DMA, 68030, cache > Summary: A2090 controller and the 030 cache (...?) > Um, Dave, I have a CBM A2090 with two ST506 hard drives. I'm also > interested in putting a GVP '030 or CBM A2630 on my system to improve > performance. Do you know when Commodore will be revising the 2090 > driver to deal with the 68030 cache? Well, um, er, actually, I'm not sure. Part of the problem is that the current methods for this are the singular method of checking for an '030 after the DMA, and if it's seen, calling a Supervisor() function that'll clear the cache. Anyone can add that to their driver, but the A2090 driver will undoubtedly be in for several enhancements, this probably being the least of them. I suspect you'll know when the driver's out; I, being a 2090A and '030 user, will certainly mention it here when it does come about. Hopefully in the future we'll have an OS call that fully solves the cache dump problem. You can now write code that'll dump an '030 cache, but it's not going to help with some great and new external cache, which you may get some day. The OS call will work with any possible configuration, '030, external, '040, whatever. > Or, :-(, should I wait for the Amiga 3000? [I'll probably get one > eventually anyway... What will the 3000 have for specs?] Oh, the usual, names and numbers, like any other machine's specs, only way cooler.... > -- John > > ------------------------------------------------------------------------------- > -- John Lockhart > jwl@feanor.stanford.edu BIX: jlockhart -- 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
daveh@cbmvax.UUCP (Dave Haynie) (06/12/89)
in article <11044@mcdphx.phx.mcd.mot.com>, dbk@teroach.UUCP (Dave Kinzer) says: > Keywords: Cache > Summary: More Cache warnings > Unfortunately, I have been known to load a program or two in my usage of > my Amiga. If the program is transfered using DMA, there is a possibility > of stale data in the instruction cache. In practice, this never happens. The process of loading new code is enough to overwrite the instruction cache, and _probably_, but not at all certainly, the data cache (which is why we don't recommend running DMA and data cache unless the device driver for the DMA hardware flushes the cache). > The 68030 cache is not exactly a Most Recently Used cache, Well, yes and no. The caches on both '030 and '020 are straight mapped 256 byte caches. They're organized a bit differently, the '030 caches are both 16 entries of 4 longword lines, I don't recall the exact organization of the '020 cache. Minimally, though, in either case you overwrite a cache entry by accessing an item on the same (address % 256) location. So if you wanted to make sure a data item wasn't cached, you could read that location plus 256 (assuming that location's cachable), and you're guaranteed you won't take a cache hit at your original location. For instruction code, you'll absolutely know you're not getting stale instructions if you've run code at 256 consecutive locations (no more that 128 instructions), or the equivalent, before running your newly loaded code. It's actually even less that that, because the '030 doesn't deal with individual words, it invalidates in terms of cache lines. So in best case, you can completely overwrite the instruction cache in 16 properly placed instructions (each entry in a cache line has the same cache tag address, but can be independently validated. When you change the tag address by caching one longword, the other three are invalidated). Note that this is all very '020/'030 specific; the '040, or either '020/'030 with external cache, will no doubt behave very differently. You'll likely have more obvious cache support in the OS by then, though... >some stale data can exist even after thousands of instructions have been >executed (though not likely [read infrequent guru]). That could happen, I suppose, but you'd almost have to design the example yourself, and you'd have to be pretty clever about locating your code as well. You'd certainly have to avoid using the OS LoadSeg() call, the use of which appears guaranteed to overwrite the '030 cache. > I seem to recall a flush cache system call, but I could not find it in > about 2 minutes of looking. Nope, none was required for '020 support (instruction cache only), which is as far as 1.2/1.3 took cache support. > If it does not exist, it needs to (can you say 1.4 wish? I knew you could.) I agree. > It perhaps should be implemented as something external to the system > (Romtags?), so as new processors become available it can be easily changed > (Also changable for aftermarket cache boards should they become available.) Well it's only one function, I'd think. I suppose a future OS would provide an Exec call that knows how to flush the cache on machines it understands. If you added a new CPU (like perhaps an '040) or new external hardware (an external cache on an '030 possibly), you'd provide a driver for that board, perhaps even automatically bound via the BindDrivers facility, that would SetFunction() the required cache calls and at the same time enable the unknown cache(s). > > Any task that is in control of DMA (say, the trackdisk device) would call > this routine after the DMA is finished. The routine would flush the cache > if it exists. Yup. > | // GOATS - Gladly Offering All Their Support Dave Kinzer (602)897-3085| > | // >> In Hell you need 4Mb to Multitask! << uunet!mcdphx!teroach!dbk | > | \X/ #define policy_maker(name) (name->salary > 3 * dave.salary) | -- 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
lphillips@lpami.wimsey.bc.ca (Larry Phillips) (06/12/89)
In <11044@mcdphx.phx.mcd.mot.com>, dbk@teroach.UUCP (Dave Kinzer) writes: > Unfortunately, I have been known to load a program or two in my usage of >my Amiga. If the program is transfered using DMA, there is a possibility >of stale data in the instruction cache. The 68030 cache is not exactly >a Most Recently Used cache, some stale data can exist even after thousands >of instructions have been executed (though not likely [read infrequent guru]). Good point. I hadn't thought about the problem in terms of size of cache, figuring that by the time another program got loaded, there wouldn't be any trace of the old contents lying around in the cache. > I seem to recall a flush cache system call, but I could not find it in >about 2 minutes of looking. If it does not exist, it needs to (can you say >1.4 wish? I knew you could.) It perhaps should be implemented as something >external to the system (Romtags?), so as new processors become available >it can be easily changed (Also changable for aftermarket cache boards should >they become available.) I can't find it either. You may have been thinking of CMD_FLUSH for IO, or FlushCList, which are the only references to 'flush' I can find in autodocs. > Any task that is in control of DMA (say, the trackdisk device) would call >this routine after the DMA is finished. The routine would flush the cache >if it exists. Wouldn't it have to call for a flush before IO started? -larry -- Van Roy's Law: An unbreakable toy is useful for breaking other toys. +----------------------------------------------------------------------+ | // Larry Phillips | | \X/ lphillips@lpami.wimsey.bc.ca or uunet!van-bc!lpami!lphillips | | COMPUSERVE: 76703,4322 | +----------------------------------------------------------------------+
usenet@cps3xx.UUCP (Usenet file owner) (06/13/89)
In article <7081@cbmvax.UUCP> daveh@cbmvax.UUCP (Dave Haynie) writes: >in article <9831@polya.Stanford.EDU>, jwl@Feanor.Stanford.EDU (John Lockhart) says: >> Keywords: A2090, hard drive, DMA, 68030, cache > [stuff deleted] >> driver to deal with the 68030 cache? [stuff deleted] >DMA, and if it's seen, calling a Supervisor() function that'll clear the cache. [stuff deleted] Dave, does the '030's data cache cause problems when (real hardware)device drivers play with the devices memory-mapped IO registers? How about another flag in task/interrupt structures telling EXEC to turn off the data cache when executing this chunk of code. Even better "MEMF_NOCACHE" :-), but I don't think you can do that with the MMU, can you? This is an example of a short .signature jap@frith.cl.msu.edu
451061%UOTTAWA.BITNET@cornellc.cit.cornell.edu (Valentin Pepelea) (06/14/89)
<usenet@cps3xx.uucp> writes in message <3374@cps3xx.UUCP> > How about another flag in task/interrupt structures > telling EXEC to turn off the data cache when executing this chunk of > code. Even better "MEMF_NOCACHE" :-), but I don't think you can do > that with the MMU, can you? You can for external caches, not the internal ones, using the CI (cache inhibit) bit in page descriptors. > Usenet file owner Get a name, will you? Valentin _________________________________________________________________________ The godess of democracy? "The Name: Valentin Pepelea tyrants may distroy a statue, Phonet: (613) 231-7476 but they cannot kill a god." Bitnet: 451061@Uottawa.bitnet Usenet: Use cunyvm.cuny.edu gate - Confucius Planet: 451061@acadvm1.UOttawa.CA
mph@behemoth.phx.mcd.mot.com (Mark Huth) (06/15/89)
In article <7083@cbmvax.UUCP> daveh@cbmvax.UUCP (Dave Haynie) writes: >in article <11044@mcdphx.phx.mcd.mot.com>, dbk@teroach.UUCP (Dave Kinzer) says: >Well, yes and no. The caches on both '030 and '020 are straight mapped 256 >byte caches. They're organized a bit differently, the '030 caches are both >16 entries of 4 longword lines, I don't recall the exact organization of >the '020 cache. Minimally, though, in either case you overwrite a cache >entry by accessing an item on the same (address % 256) location. So if you There are 64 cache lines in the '020 instruction cache. Instructions with a different tag for each longword (64 all together) must be fetched - not necessarily executed to ensure that the cache has been invalidated with regard to previous cache contents. This is quite common, and it should be possible to determine that the execution of a particular piece of code will overwrite the cache, probably removing the need to invalidate the '020 instruction cache. The '030 caches have been reorganized into 16 line by 4 longword organization in order to allow burst fill operation. In this mode, given a properly designed memory system, the first memory cycle may require a minimum of two clock cycles, and the next three sequential locations may require a minimum of 1 additional clock cycle for each longword. DRAM chips with nibble modes support this type of operation. Mark Huth
mph@behemoth.phx.mcd.mot.com (Mark Huth) (06/16/89)
In article <17588@louie.udel.EDU> 451061%UOTTAWA.BITNET@cornellc.cit.cornell.edu (Valentin Pepelea) writes: > ... stuff about using '030 mmu to inhibit cache >You can for external caches, not the internal ones, using the CI (cache >inhibit) bit in page descriptors. Wrong, then internal caches of an '030 are also inhibitted by the CI bit in the MMU page descriptor. >Get a name, will you? Get an '030 manual - then read it. 8-) sorry, couldn't resist Mark Huth