Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!mimsy!oddjob!hao!noao!mcdsun!fnf
From: fnf@mcdsun.UUCP (Fred Fish)
Newsgroups: comp.sys.amiga
Subject: Re: Amiga: Which replacment OS?/UN*X ??
Message-ID: <330@mcdsun.UUCP>
Date: Fri, 3-Jul-87 17:34:19 EDT
Article-I.D.: mcdsun.330
Posted: Fri Jul  3 17:34:19 1987
Date-Received: Sun, 5-Jul-87 05:35:46 EDT
References: <600@gryphon.CTS.COM> <1705@vdsvax.steinmetz.UUCP>
Reply-To: fnf@mcdsun.UUCP (Fred Fish)
Organization: Motorola Microcomputer Division
Lines: 24

In article <4237@jade.BERKELEY.EDU> mwm@eris.BERKELEY.EDU (Mike (My watch has windows) Meyer) writes:
>The ability to ignore memory limitation just leads to lots of
>programmers who ignore memory limitations.  The result is usually
>larger, slower code to do the same thing that a non-vm system would
>do, and enormous code with lots-and-lots of features.

I have a direct counter-example.  A couple months ago, as part of an internal
research project where we needed to have the Unix linker do something
that it was never intended to do, I completely rewrote the COFF SVR3 linker
from scratch.  One of the basic assumptions was a virtual memory environment
were I could just suck all the required files into memory at once, do the
link (and our other stuff) and write out the executable (single read/write
calls for each file).  

The resulting linker is four times smaller than the standard COFF linker
and anywhere between 4-10 times faster depending upon the sizes and number
of the files linked.  The original COFF linker (written for a non-vm
environment) is far too feature laden, complex, and slow.

-Fred
-- 
= Drug tests; just say *NO*!
= Fred Fish  Motorola Computer Division, 3013 S 52nd St, Tempe, Az 85282  USA
= seismo!noao!mcdsun!fnf    (602) 438-5976