Heading:qjk40(635)
Potential Tamarin Simplificationsy756qjk40
Page Numbers: Yes  X: 527  Y: 10.5"qjk40
Inter-Office Memorandumz18592l4445y762\f5b
To	Beau Sheil	Date	June 17, 1985z18592l4445d2998e21(0,65535)(1,4445)(5,11684)(6,14146)\f1 2f0t2 1t0 10t6 1f1t0 4f0t7 1t0
From	Alan Bell	Location	Palo Altoz18592l4445d2998y716e25\f1 4f0t2 1t0 9t6 1f1t0 8f0t7 1t0
Subject	Potential Tamarin Simplifications	Organization	PARC/ISLz18592l4445d2998e25\f1 7f0t2 1t0 33t6 1f1t0 12f0t7 1t0
XEROX       z18592l508y644e14(2116)\f2 5f0
e10
In our meeting you asked me to set forth the aspects of the Lisp system that Tamarin proposes changing.  The purpose is to create a starting point to see how the amount of software work can be reduced.  This memo describes the changes I proposed for Tamarin.  As we discussed in the meeting, you can now assess the effort savings involved in each task.e12jk40
* 16 to 32 bit word sizee12jk40
Our existing architecture is built around 16 bit memory references.  The proposal would change this to a full word quantity (32 or 40 bits).  This change is fundamental.  If it is not made, few other changes could be made.  This is conceptually simple and would require little design time.  There are many places in the system that would have to be modified.  The conversion effort would be large.e12jk40
* Tagged architecturee12jk40
The existing machine uses a table indexed by high-order address bits to determine the type of an object.  The proposal would include the type explicitly in the pointer.  Both the design work and conversion work is small.  The concept of type is still in the system.  Accessing the type is done primarily through opcodes that would be the same.e12jk40
* 40 vs. 32 bit architecturee12jk40
Tamarin proposes a 40 bit architecture.  It is possible to use a tagged 32 bit architecture.  The biggest difficulty in going to 40 bits is that I/O will have to deal with the extra byte.  This will make the hardware slightly more complicated.  After having tags, going to 40 bits doesn't cost much.  A 32 bit architecture would preclude immeadiate floating point numbers.e12jk40
* Reference Counte12jk40
I have proposed changes to the reference count algorithm.  These changes reduce the problems associated with programs that contain objects that are pointed at by many pointers.  This could be defered.e12jk40
* Cdr codee12jk40
With the Tamarin pointer format, the existing cdr coding algorithm will not work.  I have proposed another algorithm with a 2 bit cdr code field.  This could be defered by turning off cdr coding in the system.  There is an existing switch to do so.  Not having to include cdr coding on the first machine would simplify the hardware design.e12jk40
* Indirect Pointers on the stacke12jk40
I proposed allowing indirect pointers in the VARS section of a stack frame.  This was prompted by split frame spaghetti stacks.  Bill vanMelle and Danny Bobrow agreed that slight changes could be made to spaghetti stacks.  Frames would no longer ever be split.  Whenever a frame was to be copied, the whole frame, not just the frame extension, would be copied.  Both Bill and Danny felt that no ones code would notice this change.  Therefore, the indirect pointers are not required.  CommonLisp may require these indirect pointers to handle closures.e12jk40
* Maximum Stack Sizee12jk40
Tamarin requires that frames have a maximum size of about 50 pointers.  This will require new mechanisms to handle frames that are larger than this size.  An overflow mechanism is also required if the number of arguments is greater than 8.  This change is fundemental to Tamarin.e12jk40
* Bind/Unbinde12jk40
Tamarin proposes changes in the way Bind and Unbind work.  The compiler will have to be changed to keep track of stack level at all times.  This change is an effect of the way the stack will be handled.e12jk40
* Opcode changese12jk40
The opcode set is conceptully the same as the previous opcode set in most places.  Most opcodes have slight changes to them.  This will mean some changes to the compiler.e12jk40
* CommonLisp, Prologe12jk40
Tamarin does not have easily modifiable microcode.  This means that the microcode has to be well thought out before the silicon is submitted.  The microcode changes to handle CommonLisp and Prolog will have to be thought ahead of time.  If CommonLisp and Prolog are not to be included in the first machine, considerable time would be saved.e12jk40
* I/O changese12jk40
The peripherals on Tamarin will be completely different.  They will require Lisp software work to drive the peripherals.  If Tamarin were put on an IBM PC bus and the peripherals put on that bus, then the IBM PC could drive the peripherals.  An existing OS could be used.  This would not affect the performance of Tamarin running in-core programs.  It might affect swapping performance.  This alternative would eliminate one custom chip in the short term.e12jk40
e12jk40
c: John Brown
Johan deKleer
Steve Purcell
l3528d2998e12j
e12j