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