Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!rutgers!ames!ucbcad!ucbvax!INGRES.BERKELEY.EDU!hatcher
From: hatcher@INGRES.BERKELEY.EDU.UUCP
Newsgroups: comp.sys.amiga
Subject: Re: True Multitasking, and some history lessons
Message-ID: <8706200609.AA19016@ingres.Berkeley.EDU>
Date: Sat, 20-Jun-87 02:09:56 EDT
Article-I.D.: ingres.8706200609.AA19016
Posted: Sat Jun 20 02:09:56 1987
Date-Received: Sun, 21-Jun-87 05:17:45 EDT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: University of California, Berkeley
Lines: 44
Summary: More history, plus some tradeoffs

In article <307@trwspf.TRW.COM> dragon@trwspf.TRW.COM (Roger Vossler) writes:
In article <163@sugar.UUCP> peter@sugar.UUCP (Peter DaSilva) writes:
*UNIX programs tended to be small and tight. It used to be that you could code
*the world in 64K.

>Amen, brother, Amen! And we did code the world in 64K, too, clobbering some
>of our competitors in the process. I struggled for five years ('75->'80) to

I recall that one of the first versions of vi that Bill Joy wrote on
a PDP 11/70 running Version 6 Unix (around 1977, I think) had some
interesting features like automatic spelling correction (by choosing
from a list of replacements), and document preparation features like
continuous paragraph reformatting. He eventually deleted them, though
(much to some people's dismay) because "I only have 5 bytes left in
the 64k code segment; I can't include *everybody's* favorite features!"

So I'd say that while the blessing was that many programs were small
and tight, the curse was that this was at the expense of some functionality
in the largest programs (at the time vi was considerably larger than the
entire version 6 Unix kernel in terms of pages of printout).

For some years I've luxuriated in having more than 64K to build sophisticated
programs, but over the last couple of years I've found that there is
*always* something to be said for "small and tight", too. Like many
others, I have often written code that took up an extra 60K unnecessarily
because it was easier to write it that way, and the 60K was available.
Sometimes this is reasonable, but it is a very bad *habit* to get into
when performance is an issue. One fun thing about the Amiga is that
it is giving me an opportunity to consider making things smaller to
conserve *disk* space, if nothing else, which helps me break some sloppy
habits. But it still has plenty of RAM (and disk space) for programs that
*need* to be big. What fun!

For those of you that don't care much for issues of disk space, note
that smaller programs tend to run faster, too, if you can trim them
down enough to use 16 bit rather than 32 bit pointers. This is not true
of all architectures, of course, but note that what *is* universal is
that the more memory a program uses, the more memory cycles it will use
to fetch/store/execute, and therefore is slower than the same program
rewritten to be smaller and use fewer memory cycles (all other things
being equal, of course...often the algorithm chosen is the most important
thing [flame avoidance :-] )
	Doug Merritt		ucbvax!ingres!hatcher (thru Jun 28)
			or	ucbvax!unisoft!certes!doug