Path: utzoo!utgpu!attcan!uunet!cbmvax!ditto
From: ditto@cbmvax.UUCP (Michael "Ford" Ditto)
Newsgroups: comp.sys.amiga.tech
Subject: Re: Need info on exceptions
Summary: Virtual address space would be OK
Keywords: Virtual memory, Address space
Message-ID: <4652@cbmvax.UUCP>
Date: 3 Sep 88 01:22:03 GMT
References: <8808272322.AA03740@cory.Berkeley.EDU> <125@fishpond.UUCP> <39432@linus.UUCP>
Reply-To: ditto@cbmvax.UUCP (Michael "Ford" Ditto)
Organization: Commodore Technology, West Chester, PA
Lines: 75

In article <39432@linus.UUCP> eachus@mitre-bedford.arpa (Robert I. Eachus) writes:
>                                              AmigaDOS  2.0 might also
>provide  virtual memory, such that not  all valid memory addresses are
>mapped  to  hardware memory.    (Again  not  too   difficult.   Memory
>requested as CHIP memory, of course  cannot be made  virtual, and some
>DMA disk controllers would  need to  be made smarter, but overall  not
>too bad.)

This would have some serious ramifications to device drivers.  Any
interrupt-driven driver, for example, would have to be treated specially
so that all of its code, data, stack, and I/O buffers would always be
resident.  An inherent characteristic of Exec's I/O system is that
I/O is message based, and there is no distinction whether a message
will be handled/replied to by another process, an interrupt, or some
combination.

There is actually very little that distinguishes device driver code from
"user" code, and under the current system, any program may suddenly
decide to make itself a "device driver" by creating a device node and
starting to handle I/O reqests.  If its operation requires real-time
response to hardware events, it must never be out of memory.  Also,
there are Exec functions like AddIntServer() which cause some code
and data of the calling program to be referenced/executed at interrupt
time.  Somehow, the O.S. would have to be told that these data areas
must never be paged.

Most of the above problems are just special cases of a more general
statement:  Amiga Exec is a REAL TIME operating system.  I think it
would actually be easier to add real-time capability to Unix than it
would be to add virtual memory to Exec/AmigaDOS in a way consistent
with their design philosophy.

One way to reduce the problem would be to add YAAF (Yet Another AllocMem
Flag): MEMF_PHYS(?) which would return memory that would never be paged.
Then, another flag in object hunks would be needed, and an option to
fixhunk, etc....

>     HOWEVER, to add    virtual address  spaces to  KickStart/AmigaDOS
>would  be a messier project than  replacing  MS-DOS with OS/2! (And it
>would  sell about as  well  because it  would be   at least as fat and
>slow.)

I don't see any reason why that should be so.  Virtual-to-physical
address translation doesn't necessarily take any more time than access
protection and it doesn't increase memory usage (except perhaps for the
code to implement it).  If by "fat" you mean "encouraging development
of memory-hungry software" that has nothing to do with address
translation.

>          In single-user multitasking systems, unlimited address space
>(as opposed to a finite but large address space) is not worth the pain
>and agony.

There's no such thing as unlimited address space.  Since (as far as I
can follow your message) we are talking about virtual address space,
not virtual memory, the only difference would be that two processes
could have their memory at the same address.  This does not change
the size of the address space, it only changes which parts of it are
available.  Virtual address translation could add several important
benefits to the Amiga, including shared/reusable code (without having
to use special compilers and programming methods).

>     To sum up: 

>     Adding virtual address spaces to AmigaDOS would be a big mistake
>under any circumstances.

I disagree.
-- 
					-=] Ford [=-

	.		.		(In Real Life: Mike Ditto)
.	    :	       ,		ford@kenobi.cts.com
This space under construction,		...!ucsd!elgar!ford
pardon our dust.			ditto@cbmvax.commodore.com