Path: utzoo!utgpu!water!watmath!clyde!att!ucbvax!hplabs!pyramid!cbmvax!jesup
From: jesup@cbmvax.UUCP (Randell Jesup)
Newsgroups: comp.sys.amiga.tech
Subject: Re: Address Space on the Amiga (was Re: Need info on exceptions)
Keywords: Queen's -, Florida -s
Message-ID: <4605@cbmvax.UUCP>
Date: 30 Aug 88 20:59:57 GMT
References: <8808272322.AA03740@cory.Berkeley.EDU> <125@fishpond.UUCP> <3859@hcr.UUCP>
Reply-To: jesup@cbmvax.UUCP (Randell Jesup)
Organization: Commodore Technology, West Chester, PA
Lines: 66

In article <3859@hcr.UUCP> edwin@hcrvax.UUCP (Edwin Hoogerbeets) writes:
>In article <125@fishpond.UUCP> fnf@fishpond.UUCP (Fred Fish) writes:
>>In article <8808272322.AA03740@cory.Berkeley.EDU> dillon@CORY.BERKELEY.EDU (Matt Dillon) writes:
>>>: [somebody besides Matt writes]
>>>:				An idea central to the Amiga
>>>:is that an address in any tasks address space is not a virtual 
>>>:address but a physical memory address. That means that you can hand 
>>>:a pointer off to another task and it will be valid in THAT tasks's address
>>>:space.
>>>	Yes, this *IS* a nice idea.
>>Personally I think this is the single biggest problem with the Amiga.  

	Well, in some ways it's one of it's biggest wins, as well.  It makes
for VERY fast (but simple) IPC, which the OS relys on heavily.  Removing that
from the OS would make it grind to a (comparitive) halt.

	This was the reason for MEMF_PUBLIC.  Unfortunately, what should be
public is not clearly defined, and many of the RKM examples do things like
have static msgports (instead of allocating them with memf_public).  Also,
memf_public is a bit weak as a metaphor, and the lack of consistency of use
would cause great problems in enforcing it.

	You could _almost_ ignore public with several tricks, except for
one thing: private msgports.  They would be in the tasks address space,
and the OS has no way of knowing that they should be writable by another
task.  Public msgports aren't a problem, since they are registered with
the OS.

	This would require lots of mods to things like putmsg, and all
device drivers would have to run in supervisor mode.  Programs that pass
ptrs to other application processes would have to be reved, or run in
some compatiblity mode.  The alternative is to make most memory (or all)
readable to all processes.

	For this, there would have to be one flat address space for all
processes (not a really bad idea, it saves LOTS of virtual->physical
mapping calls, and makes the OS much less monolithic than the Unix
kernal.

	Overall, this hypothetical OS would be more resistant to crashes,
though not 100%.  Drivers and handlers would have to be trusted.  Libraries
would have to be rewritten, and would be slower for anything that had to
reference information in the library base (or elsewhere). And obviously,
you'd have to run it on an '020 with MMU (or design a custom mmu for the
68000, but then performance would likely be lousy.)

>I agree with Fred. The idea of a process is that the situation should
>look, to the process itself, as if it is the king of the CPU. No-one
>else is on this machine. If communication should occur, then you should
>assume the process you are talking to is on another machine (when it
>really is on the same one, but hey, let's be sneaky and not tell the
>first process about it!) This is the theoretical "higher concept".

	For this level of communication, see peter et al's IPC stuff.

>However, I can see how no mmu/memory protection/etc. can appeal to
>hackers. "Do what I say, and I'll be happy." Matt and others have
>produced some very nice software because of it. Also, passing messages
>and data structures by pointer is FAST. Also, queues are a lot shorter
>because you are only passing 32 bit quantities.

	The FAST bit is the important bit.  memory allocation is slow,
and so is copying, especially when you're dealing with bitmaps...  :-(

-- 
Randell Jesup, Commodore Engineering {uunet|rutgers|allegra}!cbmvax!jesup