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)