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

This memo is the result of some thoughts following a June 4 meeting discussing the future of Tamarin with Beau Sheil and Steve Purcell. The basic conclusion of that meeting was that the software effort required for Tamarin was greater than they could expend. For AISBU to provide any more software design support, the machine would have to be redesigned in a manner that would significantly reduce the software effort required. Secondly, demonstratable imtermediate milestones need to be formulated and met. I feel that the first task will be difficult, if possible.

This has caused me to rethink the motivations that prompted the Tamarin project. The meeting provided me with new information about many constraints on the hardware needs in AISBU. These constraints have significantly changed since the Tamarin project was formulated. These changes have caused me to wonder whether Tamarin is the most appropriate hardware project for AISBU or whether there might be other alternatives that would better satisfy the short-term problems.

I will outline the constraints that I heard during the meeting. Then I will describe how Tamarin relates to those constraints, formulate one option and describe how it satisfies those constraints.

The AISBU has a major weakness in the high-end market. For all practical purposes AISBU does not have a high-end machine. Even if AISBU aggresively sells the Dorado, it could only stay cost competitive for a limited time. The Daybreak does a good job of satisfying the low-end market. Therefore, AISBU’s short-term need is for a high-end machine.

There is a need to eliminate risk. We need new products as soon as possible. If we dedicate our scarce resources to an option that does not pan out, the AISBU could be seriously damaged.

Software resources are very scarce. The market needs many improvements and new software features in the Lisp system. The software staffing is below adaquete levels. It has been very hard to find qualified people. Any effort that uses software resources will reduce what we can do to other parts of the Lisp system. Therefore, all software efforts should be minimized. Wizard time is particularly scarce.

The virtues of the Tamarin project are in its long-term goals. It has the promise of providing a spectrum of hardware alternatives with excellent cost performance characteristics. It will cause a good VLSI capability to be developed in AISBU. It will cause many fundemental changes in the low-level Lisp system to occur.

The Tamarin project does a good job at addressing long-term problems but a poor job at addressing the short term constraints described above. Initially, Tamarin is aimed low to middle end. Because of the software and hardware effort, the time to product is longer than marketing wants. It has a high amount for risk involving schedule and performance. It requires a large amount of software changes to support its development. It is visible as a project because it is building not buying a workstation.

The "ideal" machine would be a high-end machine which executes the existing opcode set. Its overall completion date should be soon. It’s performance should be predictable at the start of the project. It should be based on commercial parts as much as possible without compromising performance.

Let me propose such a machine. The machine would be built around a VME bus. It would use commercial I/O controllers, commercial dynamic memory boards, a commercial microcomputer board for I/O and operating system tasks, commercial VME backplane and packaging, and the I/O processor would run a commercial operating system. The custom part would be the processor board. This would be built out of discrete TTL components and be contained on a large VME board. A second board would be required for fast static (40-70 ns) memory. This memory would act as a very large (1MB) cache. I have many specific technical ideas about the form of the machine.

The processor would utilize concepts derived from the analysis of Lisp. It would use a 32 bit word and datapath size. It would require only minimal changes to the opcode set (dealing with 32 bits not 16 bits). It would have the performance 2 times a Dorado at half the cost. The design effort would be smaller than Tamarin. After the design was completed, it could be given to Terry Haney to be prototyped using commercial firms.

Can this machine be designed and can it be done as a small effort? I think the a priori answer is yes. The available TTL technology has improved since the design of the Dorado. Much larger memories - RAM, PROM, etc - are available. PAL chips are available. This makes design simpler. The Tamarin project has provided insight into what hardware features are need to run Lisp efficiently. Much of the complexity of the Dorado is not required. By adding the features that Lisp needs, the machine does not need the same raw hardware performance to get the desired overal performance.

Such a machine satisfies the short-term constraints. It could be completed soon, it has less risk, it requires much less software work, particularly wizard time, and many of the pieces are commercially bought not built. It would provide ISL with a better research machine. However, it compromises the long term. It would delay or possibly eliminate Tamarin. Maybe AISBU needs to concentrate on the short term so that it will still be around in the long term.

I suggest this idea as a strawman. I envision two possible results of this memo. One would be to pursue the idea further by examining the technical ideas, the expected performance, project schedules, etc to assess whether the idea is viable. The other result would be to refine my understanding of the constraints on AISBU’s hardware needs.