Newsgroups: comp.sys.next
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!sdd.hp.com!news.cs.indiana.edu!jashley@tope.cs.indiana.edu
From: J. Michael Ashley <jashley@tope.cs.indiana.edu>
Subject: Re: Small executables (was Re: 16mb minimum for next machines)
Message-ID: <1991May2.100633.12905@news.cs.indiana.edu>
Organization: Computer Science, Indiana University, Bloomington.
References: <NZg714w164w@ersys.uucp> <1991May1.062022.1056@nntp-server.caltech.edu> <1991May2.142103.6047@potomac.ads.com>
Date: Thu, 2 May 91 10:06:12 EST

In article <1991May2.142103.6047@potomac.ads.com> jtn@potomac.ads.com (John T. Nelson) writes:
>
>... ahem yes well all this talk about the size of binaries implies
>that compiler writers are no longer concerned with space effeciency as
>they used to be since internal memory is now cheap as dirt and
>besides, you've got virtual memory so no problem right?

Compiler writers still have to worry about page faults, so the issue
is not entirely ignored.  

> Hmmmm...
> still compilers should be more effecient about what they generate.

A compiler could generate a relatively small amount of target code, but
that code would probably run slower than the code produced by a compiler
that strategically unrolled a few loops and inlined a couple of procedure
calls.

It's a tradeoff, and with virtual memory, most people would prefer to
see faster code at the expense of code size.  If people cared about
code size, you would see such statistics in benchmarks.

Sensible compiler writers will consider the amount of code generated
by their compilers and make the tradeoffs they see as appropriate.

Mike
