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