Path: utzoo!utgpu!water!watmath!clyde!att!pacbell!ames!think!bloom-beacon!mit-eddie!bbn!rochester!cornell!batcomputer!itsgw!steinmetz!uunet!portal!cup.portal.com!doug-merritt
From: doug-merritt@cup.portal.com
Newsgroups: comp.sys.amiga
Subject: Re: Amiga UNIX
Message-ID: <6723@cup.portal.com>
Date: 21 Jun 88 14:17:42 GMT
References: <211@laic.UUCP> <3663@cbmvax.UUCP> <1872@sugar.UUCP> <134@ssdis
Organization: The Portal System (TM)
Lines: 67
XPortal-User-Id: 1.1001.4407

David Albrecht responds to Peter da Silva:
>Point granted but confusing.  Why use a catch-all term when it isn't
>appropriate.  Yes, the 68000 support memory protection and page relocation
>etc.  By my definition, however, it doesn't support an 'MMU' unless it
>supports all the functions of a typical device which falls under this
>designation i.e. including demand paged VM.  I guess your definition for
>'support' is a little different.

Both of your definitions are fairly common usage, so you are both right.
I found out the hard way, though, that if you *mean* demand paged (say
in writing a requirements document), you must *say* "demand paged",
otherwise the ambiguity in other people's interpretation of your comments
will bite you.

In general, "Memory Management Unit" is a very general term (think about
the individual words), yet people will tend to interpret it in terms of
what they are used to. I used to program on 8080's and z80's, and I
would have loved to have any kind of MMU at all, regardless of definition.
(And eventually got the manufacturer I worked for to add in a simple
memory base segment protection MMU, but that's another story.) I've
programmed in the 80286 and the PDP 11/70 environment, and its MMU is
far better than having none at all, even though it doesn't support demand
paging VM.

To say that such machines do not have an MMU is only going to create
confused conversations with people with that kind of background, since
to us it has become very clear that it is very useful to have a way
to keep buggy programs from bringing down the whole system. And since
this more general usage of the term MMU is very common industry-wide,
and since there's good logical reason to use the term generally, you're
not going to be able to change other people's usage.

Nor do I expect to keep people from saying MMU when they mean "demand
paged VM", I just ask for clarification as to which *kind* of MMU they
mean.

I've also worked with VAXEN, DEC 20's, Suns, and other systems with
demand paged VM, and I agree that all that is real nice. I've even
spent considerable time on a mainframe VM architectural design project.
It seems that the more different environments I've encountered, the
less I feel like there's only one way to do things, or only one definition
of technical terms.

>I wouldn't say that a FP chip 'supported'
>'IEEE floating point' if it only did add and subtract.

I would, although I qualify that as supporting "a subset of the IEEE standard".
Why belittle it??? Having only hardware FP add and subtract will still
speed up all FP operations considerably compared with having none at
all. I see no point in forcing a choice between calling something either
white or black, when you can call it a shade of grey instead.

>I respectfully suggest that conclusions drawn on a multi-variable problem
>through an intuitive leap to a pet-peeve result are often fraught with error.

I agree, and I further suggest that just about all of us make such errors
anyway. All one can do is be open minded...

>VM gives you a valuable commodity, flexibility.  You can be cheap yet
>sacrifice only performance instead of compatability.

Totally agree. Much more important point than mere terminology.
	Doug
--
      Doug Merritt        ucbvax!sun.com!cup.portal.com!doug-merritt
                      or  ucbvax!eris!doug (doug@eris.berkeley.edu)
                      or  ucbvax!unisoft!certes!doug