Xref: utzoo comp.sys.amiga.programmer:4197 comp.sys.amiga.hardware:9805
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!mips!apple!sun-barr!rutgers!cbmvax!daveh
From: daveh@cbmvax.commodore.com (Dave Haynie)
Newsgroups: comp.sys.amiga.programmer,comp.sys.amiga.hardware,adsp.sw,adsp.hw
Subject: Re: 68040 Compatibility Warning
Message-ID: <22146@cbmvax.commodore.com>
Date: 4 Jun 91 03:44:48 GMT
References: <22049@cbmvax.commodore.com> <1991Jun1.175626.3234@wintermute.north.de> <1991Jun3.163847.10733@clinet.fi> <22139@cbmvax.commodore.com>
Reply-To: daveh@cbmvax.commodore.com (Dave Haynie)
Organization: Commodore, West Chester, PA
Lines: 48

In article <22139@cbmvax.commodore.com> grr@cbmvax.commodore.com (George Robbins) writes:
>In article <1991Jun3.163847.10733@clinet.fi> dix@clinet.fi (Risto Kaivola) writes:
>> kaba@wintermute.north.de (Kai Bartels) writes:

>> >mks@cbmvax.commodore.com (Michael Sinz) writes:

>> I thought that Motorola had implemented bus-snooping to maintain
>> cache-coherency. Strangely enough, this can't keep the two caches
>> coherent with regard to each other. 

The caches sure don't snoop each other.  Cache coherency doesn't mean that
you no longer have to treat I and D space properly, it's mainly a mechanism
to properly support copyback caching.  

>The root problem is that Motorola's mental memory model doesn't seem
>to include the I=D=virtual=real=supervisor=user mode that AmigaDOS
>requires, but is oriented towards a more general "unix" model.

Actually, it pretty much does work as well under AmigaOS as UNIX, except for
a few caveats.  AmigaOS doesn't support I=D anymore than UNIX, though it's
possible to write code in AmigaOS that sets I=D (of course, you CAN do just
about anything in AmigaOS, since there's no MMU protection, but that doesn't
make it proper).  The super=user issue isn't an I-Cache issue, though it is
in the 68030's data cache.  The '030's Write Allocate mode is designed to 
handle this, and it does, but unfortunately this hits upon what we consider
a bug in the data cache mechanism: a longword write to a longword port gets
cached, regardless of the hardware caching mode, and will hit when read.  
That's not true with write allocate off, or with caching managed by the MMU.
So A3000's, the only C= sponsored Amigas with 68030s and uncachable longword 
ports, need the MMU around to work real well (the MMU isn't the only solution,
but it is the most efficient).

>In some ways, the AmigaDos software model represents an arbitrary
>"simple machine" model that could be mapped fairly closely to the
>original 68000 hardware, but is still not 100% inline with the
>overall 680X0 family architecture as it has developed. 

The main problem is that AmigaOS hasn't fully adopted the use of the MMU,
while all modern UNIX system have.  The UNIX software architecture isn't
required to build a smooth 680x0 system, but the fact that it uses the MMU
for everything helps smooth things out considerably, since most of the
cache problems are more easily or completely solved via MMU than via hardware 
of some kind.

-- 
Dave Haynie Commodore-Amiga (Amiga 3000) "The Crew That Never Rests"
   {uunet|pyramid|rutgers}!cbmvax!daveh      PLINK: hazy     BIX: hazy
	"This is my mistake.  Let me make it good." -R.E.M.