Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!cmcl2!nrl-cmf!umix!umich!pla
From: pla@zippy.eecs.umich.edu (Paul Anderson)
Newsgroups: comp.sys.amiga
Subject: Re: The Next Generation
Message-ID: <582@zippy.eecs.umich.edu>
Date: Tue, 1-Dec-87 14:31:09 EST
Article-I.D.: zippy.582
Posted: Tue Dec  1 14:31:09 1987
Date-Received: Fri, 4-Dec-87 21:07:38 EST
References: <2785@megaron.arizona.edu> <17218@glacier.STANFORD.EDU> <517@zippy.eecs.umich.edu> <1131@sugar.UUCP>
Sender: usenet@zippy.eecs.umich.edu
Reply-To: pla@zippy.eecs.umich.edu (Paul Anderson)
Organization: University of Michigan EECS Dept. Ann Arbor
Lines: 81
Keywords: MMU paging swapping
UUCP-Path: ihnp4!umich!zippy!pla


In article <1131@sugar.UUCP> you write:
>In article <517@zippy.eecs.umich.edu>, pla@zippy.eecs.umich.edu (Paul Anderson) writes:
>> >Here's my fantasy for the Amiga:
>> >68020 with MMU. NO VM.
>> There is no point in providing an MMU if tasks can still nuke each
>> other.   ... more and more VM discussion eliminated for brevity

My point of view is as follows:

I have ported something close to .5 million lines of C and FORTRAN code
to the Apollos.  I am in the process of porting about 150,000 of those
lines (Berkeley's Magic, written in C) to the Amiga.  I have found that
as the architecture of micro computers gets more sophisticated (Amiga
graphics, for example), people like myself find it easier and easier to
port workstation or mainframe code down to the smaller machines.

One significant thing I've learned from these efforts, is that in
general, as the machine becomes more sophisticated, people will expect
more of it.  That typically is going to mean larger and larger
programs, such as Magic.  Unfortunately, as programs, like Magic,
become larger and larger, it gets a whole lot harder to verify that
these programs are bug free.  Introducting a system that has the added
expense (chip cost, board space, extra wait states) of Virtual memory,
but without one of the most important benefits is ludicrous.  Building
a machine *with* virtual memory capabilities but *without* interprocess
protection is, in my opinion, a contradiction in terms.  My experience
has been that many other people share this opinion, as well.

The Apollo provides a wonderful goal for the Amiga to emulate:  it is a
high quality workstation with Extremely good software development
faculities, and has many features that are a very significant
improvement over Unix.  Some of these are related to file system
extensibility (which the Amiga should do quite nicely at, too), and
others relate to the run time library linking that allow for dealing
with large libraries in a quite sensible manner.

Now I don't for a minute think that you can have an Apollo for the
price of an Amiga, but it would be nice to have some of the more
important features namely: full interprocess protection, which to me
implies using the full functionality provided by the 68851 PMMU (paged
memory management unit).

Peter, I understand your points about paging, swapping and VM, but I'd
like you to understand my point that anything less than virtual
memory+paging+interprocess protection is a hack.  It isn't completely
useless, otherwise I would not have bothered porting Magic to the
Amiga, but charging me and thousands of others for an MMU, and then not
using it properly is bad news.

For you others concerned about performance of Apollos and Suns, I
suggest you try using an Amiga and an Apollo side by side for a year or
two.  My experience is that the Amiga is about 1/4 the effective system
speed of my Apollo DN3000.  An awful lot of this has to do with the
quality of the software on the system, including compilers, debuggers,
unix-type utilities, and other related things.  Anyone that thinks that
the quality of the software on the Amiga even remotely approaches the
quality of the system software on the Apollo really should try porting
10 or 15 megabytes of software to both before claiming it as fact.  I
know little about Suns, so I won't pretend to speak for them.   I
don't know anything about real-time computing, either, so don't
take this paragraph in that context.
>
Your comment about software breaking without MEMF_PUBLIC is well taken,
also.  Someone earlier (lost the article, sorry) mentioned that message
passing OS are wonderful.  Well, they are, but things like MEMF_PUBLIC
are part of the price we paid for AmigaDOS.

My personal suggestion is for Commodore to forget trying to slowly add
virtual memory to AmigaDOS, simply so that you can say you have it - it
just isn't enough.  It would be better to freeze what we know as
AmigaDOS, and attempt to either make porting AmigaDOS programs to Unix
as easy as possible, or create a new, or highly modified true virtual
memory, paged operating system that also allows for the existence of
one address space running a number of AmigaDOS processes.  
>--
>-- Peter da Silva  `-_-'  ...!hoptoad!academ!uhnix1!sugar!peter 
>-- Disclaimer: These U aren't mere opinions... these are *values*.

 Paul Anderson

(standard disclaimer stuff, of course)