Path: utzoo!mnetor!uunet!husc6!mit-eddie!uw-beaver!cornell!rochester!ritcv!cci632!ccicpg!harald
From: harald@ccicpg.UUCP ( Harald Milne)
Newsgroups: comp.sys.amiga
Subject: Re: Still More 68020 Questions
Message-ID: <9503@ccicpg.UUCP>
Date: 20 Jan 88 10:01:31 GMT
References: <9055@ccicpg.UUCP> <3161@cbmvax.UUCP>
Organization: CCI CPD, Irvine CA
Lines: 103
Summary: And more, more

In article <3161@cbmvax.UUCP>, daveh@cbmvax.UUCP (Dave Haynie) writes:
> in article <9055@ccicpg.UUCP>, harald@ccicpg.UUCP ( Harald Milne) says:
> 

	Well Dave, I wan't to personally thank you for your response.

	A big THANKS!

> >> 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.
> 
> I'm not exactly sure what happens here.  You'll never run into trouble 
> during task swaps, since everything running is running at a unique place
> in memory.  If a program exits and a new one is loaded into that same
> memory location, obviously the cache must be purged, providing is could
> possibly contain any reminant of that removed program at that point.  This
> isn't a very large cache we're talking about.  Maybe Andy knows the truth
> here...
> 

	Is Andy an OS guru? I'll probably get flamed for asking that.

	I know this an OS issue, and I know that as a hardware designer it
would not be fair to ask you these questions. I feel that CBM has done a
commendable job just in addressing this issue. Somebody at CBM was really
thinking, to come up with solutions to these issues. Sorry, but Im just
terribly curious about these implemention details. It's not that I'm worried
that CBM did something wrong, I'm just curious just exactly what CBM did.
I wasn't even aware that these "changes" were incorporated into 1.2. As an
idiot consumer. It's not very obvious at the consumer level.

	Of course, on usenet, it's a different story.

	Does Max Toy read this?


	Anyway, little by little, I'm putting the pieces together. 

	It's a bit painful, doing that from out "here".

	Is there any developer info attainable, that covers these issues?

> > 	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.
> 
> I read the AmigaWorld article.  I just can't think of any reason why this
> slowdown should be, other than as an "implementation detail" of the CSA
> board.  Or perhaps the Dhrystone benchmark with the cache disabled hits
> some particularly bad features of any 68020 to 68000 interface.  Have to
> try that benchmark on our board.

	Please do Dave, I certainly would like to know. In fact I really would
like to see these benchmarks run on all the consumer add-ons.

	As it stands, I would rather get a CBM supported enhancement, opposed
to third party enhancements, since CBM should know where they are headed.

	And if CBM can deliver on their promise in delivering the most cost
effective 68020/68881 or whatever solution, I for one would be one real happy
SOB.

	I for one think CBM can.

	I'm holding out.

	Make my day!

> > 	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?)
> 
> Right.  Whether you're a 68000 or a 68020.  There's the rub.

	Ahhh. Thanks Dave, maybe I can relax now!  8^)

	I would hate to be the source of disinformation.

	I will not touch what I don't know. At least not in advice. Looks like
you will not either. Commendable. Keep up the excellent work!

> I did relax a few weeks ago, but I had to fly a few thousand miles from 
> my Amigas in order to achieve this feat.

	Boy can I understand that! 

> 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!"
-- 
Work: Computer Consoles Inc. (CCI), Advanced Development Group (ADG)
      Irvine, CA (RISCy business! Home of the CCI POWER 6/32)
UUCP: uunet!ccicpg!harald