Xref: utzoo comp.sys.amiga.programmer:4431 comp.sys.amiga.hardware:10103
Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!think.com!snorkelwacker.mit.edu!bloom-beacon!eru!hagbard!sunic!sics.se!fuug!clinet!dix
From: dix@clinet.fi (Risto Kaivola)
Newsgroups: comp.sys.amiga.programmer,comp.sys.amiga.hardware,adsp.sw,adsp.hw
Subject: Re: 68040 Compatibility Warning
Message-ID: <1991Jun11.231325.8198@clinet.fi>
Date: 11 Jun 91 23:13:25 GMT
References: <22139@cbmvax.commodore.com> <22146@cbmvax.commodore.com> <22154@cbmvax.commodore.com> <107299@becker.UUCP> <22299@cbmvax.commodore.com>
Organization: City Lines Oy, Helsinki, Finland
Lines: 48

daveh@cbmvax.commodore.com (Dave Haynie) writes:

>In article <107299@becker.UUCP> bdb@becker.UUCP (Bruce D. Becker) writes:
>>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.

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

>Unless it's trying to get away with self-modifying code, an application does
>not need to know about cache issues.  If it is doing that kind of thing, it
>has the choice of "know about it" or "fail".  In a protected OS, your choice
>should be limited to "fail", since the OS will maintain code segments as read
>only.  So in either case, if you're doing the right thing, you have no problems
>and need to take no special considerations. 

While on the issue of code segments, I have a modest proposal. I hope that
this hasn't been discussed before, but:
  Before 2.0 goes into ROM, would it be necessary for the Commodore to
add a new code hunk, the type of which would be something like "pure code".
This would probably benefit future operating system designs in which MMU
would be used. In the current state of affairs there are a great number of
programs that place data in the code hunk(s). In connection with the
announcement of the new code hunk, the fact that it should contain nothing
but code would be specifically stressed. Otherwise it would be exactly like
the current code hunk thus making it relatively simple for Commodore to add
the code to support the new hunk in the program loader (in 2.0, that is).
Developers putting data in the new code hunk should get what they reserve:
almost certain unfunctionality in the future operating system versions.
Developers wanting to be compatible with an MMU-utilizing OS (as far as
it is possible) might start to use the new code hunk.
  Well, I was perhaps a bit too verbose, but anyway, what do you think?

>The programs that NEED to know about cache issues are programs that are doing
>OS type things, such as device drivers.

>>  ,u,	 Bruce Becker	Toronto, Ontario
>-- 
>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.

Risto
-- 
Risto Kaivola (dix@clinet.fi) or (Risto.Kaivola@f123.n220.z2.FIDONET.ORG)