Path: utzoo!mnetor!uunet!ccicpg!harald From: harald@ccicpg.UUCP ( Harald Milne) Newsgroups: comp.sys.amiga Subject: Re: Still More 68020 Questions Message-ID: <9055@ccicpg.UUCP> Date: 13 Jan 88 09:44:51 GMT References: <8801081459.AA16543@decwrl.dec.com> <3129@cbmvax.UUCP> Organization: CCI CPD, Irvine CA Lines: 75 In article <3129@cbmvax.UUCP>, daveh@cbmvax.UUCP (Dave Haynie) writes: > in article <8801081459.AA16543@decwrl.dec.com>, plouff@nac.dec.com (08-Jan-1988 0946) says: > > 1. When the operating system recognizes a 68020, what exactly does it > > do? Is the '020 instruction cache turned on by ROM Kernel routines (or > > elsewhere in the OS), or must the user run a separate program? > The '020's cache is turned on by the OS, and left alone after that. The OS > also sets the 68020 flag in ExecBase, and the 68881 flag if appropriate. The > GetCC() vector is also set for the 68020, and any internal OS uses of > exception stack frames (if any) are set so the OS will run just fine. But the cache must be purged at some point. If you exit a task, the code in the cache can hit again, with new code loaded into the same location, the result is disasterous. Is the cache ever purged? The OS must handle this somehow. > > 2. Other than running self-modifying code, can one get in trouble > > running with the cache enabled? > I've never found any reason to turn off the cache. There shouldn't be, provided the cache is properly handled. There must more going on than the above mentioned. > Even though the C-A board (A2620 by name) has on-board RAM, making a run > from 16 bit only RAM rather moot, I have found that with all 32 bit RAM > disabled, the 68020 system will run slightly faster than the plain 68000. A2620 eh? I like it. 8^) > This speed increase is probably attributable to caching and to the fact that > non-memory operations will still happen at 14.2MHz. I absolutely agree with that. > I don't understand > why the CSA board would run slower from 16 bit memory than the 68000, though > never having used the CSA board I'm not in a position to argue that point. > But it's obviously an implementation detail if anything, not a fundamental > problem with 68020s on the Amiga. Well to fill you in, the offending comments that appeared in the Feb issue of Amiga/World. To quote: (From page 28, first paragraph on that page) "The 68020 naturally generates 32-bit addresses and expects data in 32-bit chunks. It takes additional time for the processor to generate a 24-bit 68000 address to access the 16-bit memory of the Amiga." I think that's a bit ambiguous. The 68020 is claimed to run at 86% of the speed of the 68000. For some reason, this sound like it's running without the cache enabled. This was derived from running the Dhrystone benchmark from Fred Fish disk #1. Compiler unknown (At least to me at this moment, but I would suspect the inefficient Lattice compiler at that time period). The only explanation I have for this behaviour, is the need for an extra address cycle to get the other 16-bit quanity. (It would take 2 address cycles to get a 32-bit quanity from 16-bit memory, correct?) > Dave Haynie "The B2000 Guy" Commodore-Amiga "The Crew That Never Rests" > {ihnp4|uunet|rutgers}!cbmvax!daveh PLINK: D-DAVE H BIX: hazy > "I can't relax, 'cause I'm a Boinger!" I just can't relax either. Damm this Amiga. 8^) -- Work: Computer Consoles Inc. (CCI), Advanced Development Group (ADG) Irvine, CA (RISCy business! Home of the CCI POWER 6/32) UUCP: uunet!ccicpg!harald