Text preview for : 19780425_NoteTaker_Smalltalk_Design.pdf part of xerox 19780425 NoteTaker Smalltalk Design xerox notetaker memos 19780425_NoteTaker_Smalltalk_Design.pdf
Back to : 19780425_NoteTaker_Smallt | Home
XEROX
PALO ALTO RESEAI~CH CENTER
Learning Research Group
ApriJ 2S, 1978
To: Smalltalk Interest
Subject: NoteTaker Smalltalk Design *DRAFT*
From: Dan Ingalls
Filed on: . MAXC
General Approach
The NoteTaker Smalltalk design builds on that of its predecessor, with major changes
addressed to the foilowing improvements:
1. Full capacity performance in NoteTaker environment. It should be possible to do
...... '-'.IJJ.p'~./1I.
prlitino .... nlnhinprl "''''''.n.. ... <:I"rl or'lnhi .... c nJ\,.Jl
.... nn'nlpv ""1-101."-.1.10 nf """'--"JIJ.VJ..I1 ..... "-' tpvt \,4J..lY ,o'''"'1-'III''''IJ with
",-,"J.
1 ")QV
~.6-\,.JJ'"
A "'A
\lIArrlc Af D ...{I..J'-I
'"'JUJU.., V.l .I.'\.
'lnrl
'-'IIU
..
U.
340K byte floppy disk.
2. Identical compatibility with the D-O environment. It should be possible to run
the same save file on either machine, except in cases where advantage has been taken
of the greater virtual address space of the D-O.
3. Better real-time response through more efficient addressing, storage management
and elimination of object swapping.
4. Support for language improvements such as multiple superclasses and arbitrary
instantiation.
Pointer format
Our experience has shown 16-bit object pointers to be well-suited to a system size of 1
million words. NoteTaker Smalltalk wi1l not encode class information in the pointer as in
its predecessor for three reasons:
1. It causes inefficient use of address space for classes with few instances.
2. It makes classes very special, and thus requires an extra level of simulation to
provide arbitrary instantiation.
3. It makes arbitrary transmutation of objects effectively impossible.
Physical Storage :vtanagement
There are two principal areas of physical storage which are called the ROT (Resident Object
Table) and the data area. The ROT is indexed by object. and provides the actual core
address (24 bits) and also the reference connt of the object. The data area contains the
remaining representation of the objects, namely class link and parts. The tradeoffs in space
are interesting:
128K NoteTaker approx. 10K objects
S12K NoteTaker approx. 40K objects
D-O (I-2M paged) limit 60K objects
I
, 2
( In 128K, only 1 bit of 8 are being used for the high-order core address; one could save 10K
bytes by going to 16-bit core addresses which get multiplied by two in the interpreter. Note
that this evenword alignment gives rise to a mean waste of 1/2 word per object, or 10K
again! The argument tips much in favor of long core addresses for the larger sizes. and it
would be nice for the small system to be totally compatible.
There are two more places where we could pick up a little space. One is to pack a small
reference count in with the high-order bits of the core address; the 8086 can only use 4 of
these bits, but it would restrict 0-0 to the same range (insofar as we choose to retain total
compatibility). We could also restrict the object numbers of c1ass- I ike objects to have zero
in their low order bits so that a small reference count could be packed into those bits of the
object's c1ass link. This scheme implies that any future schemes for arbitrary instantiation
will involve an indirect ancestor link, as the ancestor can not be counted on to have such a
special object number. At this time I feel that this issue is a small one - 5K out of 128K.
and we should cling to simplicity as long as possible.
It must be possible to trade ROT allocation off against the data area, but a proportion of 1
ROT entry per 16 words of data will probably do well initially.
Thf': C'lIffent :~l1o('~tion scheme for resident data seems annronriate for the NoteTaker as well:
~ -~~t -~f- i~~-e--iis-t~--f~-r--th~-