Xref: utzoo comp.sys.amiga.programmer:4339 comp.sys.amiga.hardware:10008
Path: utzoo!utgpu!news-server.csri.toronto.edu!torsqnt!lsuc!becker!bdb
From: bdb@becker.UUCP (Bruce D. Becker)
Newsgroups: comp.sys.amiga.programmer,comp.sys.amiga.hardware,adsp.sw,adsp.hw
Subject: Re: 68040 Compatibility Warning
Message-ID: <107299@becker.UUCP>
Date: 8 Jun 91 18:54:52 GMT
References: <22139@cbmvax.commodore.com> <22146@cbmvax.commodore.com> <22154@cbmvax.commodore.com>
Organization: G. T. S., Toronto, Ontario, Canada
Lines: 26

In article <22154@cbmvax.commodore.com> mks@cbmvax.commodore.com (Michael Sinz) writes:
|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.


	                                          The Amiga OS just happens to
	give so little protection 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. 8^)




-- 
  ,u,	 Bruce Becker	Toronto, Ontario
a /i/	 Internet: bdb@becker.UUCP, bruce@gpu.utcs.toronto.edu
 `\o\-e	 UUCP: ...!utai!mnetor!becker!bdb
 _< /_	 "Ferget yer humanity, do the poot" - devo