[phylum]<CTamarin>Doc>Memo>Tamarin-changes.bravo!1

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.