Path: utzoo!mnetor!tmsoft!torsqnt!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!caen!kuhub.cc.ukans.edu!markv
From: markv@kuhub.cc.ukans.edu
Newsgroups: comp.sys.amiga.hardware
Subject: Re: Amiga Custom Chips - Mem management and resource tracking
Message-ID: <1991Apr7.154005.29511@kuhub.cc.ukans.edu>
Date: 7 Apr 91 20:40:05 GMT
References: <1991Apr3.201259.8377@engin.umich.edu> <1991Apr3.153236.1@vf.jsc.nasa.gov> <1991Apr4.034655.3681@uniwa.uwa.oz> <1991Apr4.074540.27750@mtiame.mtia.oz>
Organization: University of Kansas Academic Computing Services
Lines: 69

In article <1991Apr4.074540.27750@mtiame.mtia.oz>, jep@mtiame.mtia.oz (Jesper Peterson) writes:
> In article <1991Apr4.034655.3681@uniwa.uwa.oz> andreww@uniwa.uwa.oz (Andrew John Williams) writes:
> |Something I've always wanted to know - if the problem of no MMU in the
> |Amiga is because the messages need shared memory, why not make just that
> |little bit of memory common to any tasks that want it. The rest can be
> |protected. Add some new calls (or flags) to the OS for requesting
> |protected memory or message memory. The old software can call the old
> 
> You mean like (c.f.: exec/memory.h):
> 
> 	ptr = AllocMem( size, MEMF_PUBLIC ); 
> Of course this flag has been widely misused and any fixed amount of

Ehh, toss that.  With a new OS, rename AllocMem to OldAllocMem(), and
then provide a NewAllocMem().  OldAllocMem would always return public
memory, new AllocMem would respect the flags.  You also would need to
add some flags like MEMF_NOSWAP or such for things like DMA buffers
and Interrupt code.  Another (worse) problem, is that many programs
still use static data for public memory.  Then we just need a new
keyword like "public" that can apply to data *and* functions (for
callback support).

AllocMem() would have to get a lot more intellegent, because it would
have to manage a heap for each process (since most allocations will
never be a multiple of the page size).  A protected Amiga OS could
"partially" do away with the shared address space.  New Amiga programs
that support the new calls and flags would get a private address space
for protected non-public RAM, and maybe the stack (a Unix style stack
would be nice), and public/shared RAM would get allocated out of a
shared public pool.  Also, most "public" activity is program to
system, or at least parent to child, so the OS could be modified so
that this kind of I/O doesn't need to have explicitly public by Exec
etc, using the tasks memory map for access.  This would increase the
robustness of the system even more.

> public memory would probably disappear when you start the first
> application. Any new flag would mean old programs would never get
> any public memory. I *do* hope this will be resolved one day.

I really think it could be done.  Each "new" program gets run in its
own protected address space.  There is a non-protected address space
for true public and old style programs.  That way new programs would
only kill themselves, and old programs could only kill other old
programs.

Go one step further and provide some IPC routines that dont require
totally public RAM, that way applications could trade speed for
robustness.

Note that even old programs (in 90% of the cases) wouldn't be hard to
convert.  It would only be a matter of going back and fixing the
problem practices (most of which shouldn't be done anyways, like
misuse of the MEMF_PUBLIC flag), and recompiling.

> 
> Jesper.
> -- 
> ------------------------------------------------------------------------
> USEnet: jep@mtiame.mtia.oz.au      UUCP: ...!uunet!munnari!mtiame.oz!jep
> 90% of everything is IBM compatible - Paraphrased From Theodore Sturgeon
-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Mark Gooderum			Only...		\    Good Cheer !!!
Academic Computing Services	       ///	  \___________________________
University of Kansas		     ///  /|         __    _
Bix:	  mgooderum	      \\\  ///  /__| |\/| | | _   /_\  makes it
Bitnet:   MARKV@UKANVAX		\/\/  /    | |  | | |__| /   \ possible...
Internet: markv@kuhub.cc.ukans.edu
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~