Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site unc.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!mhuxl!houxm!vax135!cornell!uw-beaver!tektronix!hplabs!hpda!fortune!amd!decwrl!decvax!mcnc!unc!rentsch
From: rentsch@unc.UUCP (Tim Rentsch)
Newsgroups: net.works
Subject: Re: Smalltalk
Message-ID: <62@unc.UUCP>
Date: Thu, 6-Sep-84 11:25:49 EDT
Article-I.D.: unc.62
Posted: Thu Sep  6 11:25:49 1984
Date-Received: Fri, 14-Sep-84 04:47:55 EDT
References: <13112@sri-arpa.UUCP>
Organization: CS Dept., U. of N. Carolina at Chapel Hill
Lines: 13

On the question of 8MB being adequate for a Smalltalk:

An 8MB Smalltalk would be very comfortable.  Not that you couldn't use more,
you understand, but 8MB would go a *long* ways.  By contrast, commercial
Xerox Smalltalk systems provide (I think) about 2MB.

Also, just because the hardware limitation is 8MB, there is no reason that
the Smalltalk virtual address space couldn't be bigger.  Such virtual
memory systems have been done, see for example the LOOM paper in
"Smalltalk-80: Bits of History, Words of Advice".  These virtual memory
systems must be done without the benefit of hardware support, but the overhead
needn't be high, i.e., extra cycles while the interpreter does the virtual
memory check aren't as common as you might think.