Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!cbmvax!cbmehq!cbmdeo!adspdk!hclausen
From: hclausen@adspdk.CBMNET (Henrik Clausen)
Newsgroups: comp.sys.amiga.tech
Subject: Re: Memory Protection!
Message-ID: <hclausen.2309@adspdk.CBMNET>
Date: 8 Aug 90 19:37:02 GMT
References: <1145.26bd4989@waikato.ac.nz> <13693@cbmvax.commodore.com>
Lines: 32

>In article <13693@cbmvax.commodore.com> valentin@cbmvax.commodore.com (Valentin Pepelea) writes:
>The problem is not that resource tracking has not been implemented, but rather
>that resource tracking has not been promoted as a concept. Therefore we have
>software today that would barf all over resource tracking enhancements.

   Yes - if we _force_ resource protection/tracking upon them.

[ Well known and correct example of problems herein deleted. ]

   Now, if a few hooks where in there to allow applications to explicitly ask
for protected,virtual and non-shareable memory, (AllocVMem() ?) they could
benefit on the larger machines, while still running on non-MMU machines. The
programmers of large, ram-intensive applications would embrace this.
   They would still use AllocMem() for message ports and whatever else is
going to be shared with other tasks.

   For non-MMU machines, these calls would behave just like AllocMem(),
apart from the resource tracking.

   Would this break anyone? Valentin?

>>Both the ROM and bottom of memory (page zero) are write protected. Actually
>page zero is also read protected.

   That's real nice. The OS doing so, or some devilish debugging tool?

                                        Have a nice day      -Henrik

--
|            Henrik Clausen, Graffiti Data (Fido: 2:230/22.33)           |
|           ...{pyramid|rutgers}!cbmvax!cbmehq!adspdk!hclausen           |
\__"Do not accept the heart that is the slave to reason" - Qawwali trad__/