Xref: utzoo comp.sys.amiga.programmer:4214 comp.sys.amiga.hardware:9823
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!hobbes.physics.uiowa.edu!news.iastate.edu!ux1.cso.uiuc.edu!milo.mcs.anl.gov!midway!mimsy!dftsrv!ukma!rex!samsung!cs.utexas.edu!sun-barr!rutgers!cbmvax!mks
From: mks@cbmvax.commodore.com (Michael Sinz)
Newsgroups: comp.sys.amiga.programmer,comp.sys.amiga.hardware,adsp.sw,adsp.hw
Subject: Re: 68040 Compatibility Warning
Message-ID: <22154@cbmvax.commodore.com>
Date: 4 Jun 91 12:06:49 GMT
References: <22049@cbmvax.commodore.com> <1991Jun1.175626.3234@wintermute.north.de> <1991Jun3.163847.10733@clinet.fi> <22139@cbmvax.commodore.com> <22146@cbmvax.commodore.com>
Reply-To: mks@cbmvax.commodore.com (Michael Sinz)
Organization: Commodore, West Chester, PA
Lines: 83

In article <22146@cbmvax.commodore.com> daveh@cbmvax.commodore.com (Dave Haynie) writes:
>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:
>>> 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 reason is that they did not implement the hardware to snoop between the
two caches.  The implemented the snooping for the main CPU itself and both
caches go through the same external bus.

In either case, there is also the much greater chance of having the instruction
cache still think it has valid data for an address since it is now 4K long
rather than 256 bytes.

>>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

The I/D issues are just as complex for UNIX as they are for AmigaDOS.  In
general, Unix applications do not do things like allocate memory and build
code in that memory space.  However, at the UNIX kernel level, the 68040
in copyback mode has proven to cause major problems.  It turns out that UNIX
not only needs to do what we do in the cache work, they need to worry about
this caches every time a page fault happens.  If a UNIX system is very busy
page-faulting (and thus swapping to disk) the copyback mode is actually more
of a bother than a real speed benefit.

>>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.

Actually, the Amiga memory model works rather well with the new processors.
We do not make use of the fact that code and data memory spaces could
be physically different address spaces.  (Along with user and supervisor
spaces this makes for 4 separate 4Gig memory maps!)  Now, we have all of
the memory mapped to the same place, but so do most (all?) UNIX systems.
It is rather nasty when you can not access the code memory space with
a data fetch/store since it makes the loading of code rather interesting
and the use of data within the code imposible.

>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.

While some of the "cache this but not that" is much easier with the MMU
it does not, in any way, reduce the need for cache coherency code.
The MMU can not magically force data that is being loaded (for example
a what LoadSeg() does) to make sure it is in the instruction cache when
the code is executed or make sure that dirty data is not in the caches
when it is referenced.  (I really wish that were possible, but...)

The 68040 (and future processors) will continue in the trend to push
the I and D spaces further apart.  The main reason is for system performance.
(If I and D are 100% independant, you can do a fetch on both at the same time)
While most system designs will not have 100% separate I and D memory
subsystems, there well may be fancy RAM controllers that can feed the
CPUs faster.  Software will need to continue to advance in its dealings
with instruction and data space issues.  The Amiga OS just happens to
give enough flexibility at the application level that applications
have been written that will need to understand the issues of cache
coherency and separate I and D caches.

/----------------------------------------------------------------------\
|      /// Michael Sinz  -  Amiga Software Engineer                    |
|     ///                   Operating System Development Group         |
|    ///   BIX:  msinz      UUNET:  rutgers!cbmvax!mks                 |
|\\\///                                                                |
| \XX/     Quantum Physics:  The Dreams that Stuff is made of.         |
\----------------------------------------------------------------------/