Path: utzoo!attcan!uunet!cbmvax!thomas
From: thomas@cbmvax.UUCP (Dave Thomas QA)
Newsgroups: comp.sys.amiga.tech
Subject: Re: WB 1.4 (actually Amiga & MMU)
Message-ID: <5683@cbmvax.UUCP>
Date: 12 Jan 89 17:27:09 GMT
References: <277@ubc-cs.UUCP> <5062@garfield.MUN.EDU> <1424@ardent.UUCP> <760@myrias.UUCP> <1656@ardent.UUCP>
Reply-To: thomas@cbmvax.UUCP (Dave Thomas QA)
Distribution: na
Organization: Commodore Technology, West Chester, PA
Lines: 66

In article <1656@ardent.UUCP> rap@ardent.UUCP (Rob Peck) writes:
> As a followup to Chris Gray's message, what I was thinking of was something
> that would work with an MMU without much hassle.  In essence, I was thinking
> of an interface library that would for example contain functions such as:
> 
> 	RegisterMeWithSystem(); /* passes my task id in for resource track */
> 	NWindowID = AllocateStandardWindow();
> 	ModifyWindowParm(WindowID, parmValue);
> 	WindowID = OpenMyWindow(NWindowID);
> 	/* using the window here */
>    cleanup:
> 	CloseMyWindow(WindowID);
> 	DumpWindowStructure(WindowID);
> 
>    alternate_cleanup:
> 	UnregisterMe();  /* system closes all my windows and deallocates
> 			  * anything I got ID's for from kernel process
> 			  */
> 
> [by this method, trying to avoid passing pointers to MMU-protected task-
> local memory]
> 
> WindowID is an integer you get back from the kernel function that
> is actually doing the resource tracking and AllocateStandardWindow gives
> you a NewWindow structure, but managed by the system, not by the program.
> Then almost all of the interface functions shown in the sample become
> some form of message passed to the task that actually owns the chip memory.
> Though there is the overhead of the call, there may not be quite as much
> need to copy entire data structures through some commonly accessible
> memory system.  Each message passed to the kernel process includes
> the taskid (from FindTask(0)) so the kernel knows who is doing the asking
> and can track resources if appropriate.  Too much overhead?.. maybe.
>

I'm not sure whether resource tracking would involve too much overhead. My
gut feeling is that it could be handled without too much performance penalty.
I'm not so sure that I like the idea of using descriptors instead of pointers.
This would certainly break existing programs and while that could be handled
by adding things like "mmu_intuition.library" while also keeping 
"intuition.library" it would cause all sorts of message passing problems.
Probably the simplest way to use the mmu is to start making things like
MEMF_PUBLIC mean something and let each task share one large 32 bit
address space (instead of giving each task its own 32 bit address space).
I know that MEMF_PUBLIC alone won't solve the problem, but perhaps a new 
class of memory attributes...
 
> I have not thought this out very thoroughly, and have not been exposed
> too much to other OS's that might use a similar method.  Just thought
> I'd output a bit more of the thinking that prompted my original posting.
> 
> Rob Peck

I haven't thought through all the consequences either. It seems that the
OS will probably take incremental steps toward virtual memory. First
memory protection, then virtual memory. Anyway, it's an interesting subject
to talk about...

       Dave Thomas
-- 
=============================================================================
   Dave Thomas               COMMODORE AMIGA TEST ENGINEERING
  // /_ |\/||/_ /_           UUCP  ...{allegra,rutgers}!cbmvax!thomas
\X/ /  \|  ||\//  \          PHONE 215-431-9328
=============================================================================
       Opinions expressed are my own...no one else wants them
=============================================================================