DEC Prism

In the period from 1982 to 1985, no fewer than four attempts were made to create a RISC chip at different DEC divisions. Titan from DEC's Western Research Laboratory (WRL) in Palo Alto, California was a high-performance ECL based design that started in 1982, intended to run Unix. SAFE (Streamlined Architecture for Fast Execution) was a 64-bit design that started the same year, designed by Alan Kotok (of Spacewar! fame) and Dave Orbits and intended to run VMS. HR-32 (Hudson, RISC, 32-bit) started in 1984 by Rich Witek and Dan Dobberpuhl at the Hudson, MA fab, intended to be used as a co-processor in VAX machine. The same year Dave Cutler started the CASCADE project at DECwest in Bellevue, Washington.[3]

Eventually Cutler was asked to define a single RISC project in 1985, selecting Rich Witek as the chief architect. The design started as a 64-bit chip, but was later "downsized" to 32-bits. In August 1985 the first draft of a high-level design was delivered, and work began on the detailed design. The PRISM specification was developed over a period of many months by a five-person team: Dave Cutler, Dave Orbits, Rich Witek, Dileep Bhandarkar, and Wayne Cardoza. This work was 98% done 1985–86 and was heavily supported by simulations by Pete Benoit on a large VAXcluster.[3]

In terms of integer operations, the PRISM architecture was similar to the MIPS designs. Of the 32-bits in the instructions, the 6 highest and 5 lowest bits were the instruction, leaving the other 21 bits of the word for encoding either a constant or register locations. Sixty-four 32-bit registers were included, as opposed to thirty-two in the MIPS, but usage was otherwise similar. PRISM and MIPS both lack the register windows that were a hallmark of the other major RISC design, Berkeley RISC/SPARC.

The PRISM design was notable for several aspects of its instruction set. Notably, PRISM included Epicode (extended processor instruction code), which defined a number of "special" instructions intended to offer the operating system a stable ABI across multiple implementations. Epicode was given its own set of 22 32-bit registers to use. A set of vector processing instructions were later added as well, supported by an additional sixteen 64-bit vector registers that could be used in a variety of ways.

Two versions of the system were planned, DECwest worked on a "high-end" ECL implementation known as Crystal, while the Semiconductor Advanced Development team worked on MicroPRISM, a CMOS version. MicroPRISM was finished first and was sent for test fabrication in April 1988.

MICA was the codename of the operating system developed for the PRISM architecture. MICA's design was driven by Digital's need to provide a migration path to PRISM for Digital's VAX/VMS customers, as well as allowing PRISM systems to compete in the increasingly important Unix market.[4][5] MICA attempted to address this need by implementing VMS and ULTRIX "user interfaces" on top of a common kernel which could support the system calls (or "system services" in VMS parlence), libraries and utilities needed for both environments.[6]

The original goal for MICA was that all applications would have full and interchangeable access to both the VMS and ULTRIX interfaces, and that a user could choose to log in to a ULTRIX or VMS environment, and run any MICA application from either environment.[7] However, it proved to be impossible to provide both full ULTRIX and full VMS compatibility to the same application at the same time, and Digital scrapped this plan in favour of having a separate Unix operating system based on OSF/1 (this was variously referred to as PRISM ULTRIX or OZIX).[8] As a result, MICA would have served as a portable implementation of a VMS-like operating system, with compatible implementations of DCL, RMS, Files-11, VAXclusters, and the VAX/VMS RTLs and system services. Proposals were made for reinstating Unix compatibility in MICA on a per-application basis, so that a MICA application could be compiled and linked against the VMS interfaces, or the ULTRIX interfaces, but not both simultaneously.[9]

Due to scheduling concerns, Digital planned to deliver certain PRISM systems with restricted subsets of the full MICA operating system. This included systems such as Cheyenne and Glacier which were dedicated to running specific applications, and where direct interaction with the operating system by customers would be limited.[10]

MICA was to be written almost entirely in a high-level programming language named PILLAR. PILLAR evolved from EPascal (the VAXELN-specific dialect of Pascal) via an interim language called the Systems Implementation Language (SIL).[11][12] PILLAR would have been backported to VAX/VMS, allowing applications to be developed that could be compiled for both VAX/VMS and MICA. A common set of high-level runtime libraries named ARUS (Application Runtime Utility Services) would have further faciltated portability between MICA, OSF/1, VAX/VMS and ULTRIX.[13] As part of the PRISM project, a common optimizing compiler backend named GEM was developed (this survived and became the compiler backend for the Alpha and Itanium ports of VMS).[14][15]

In addition to PILLAR, Mica provided first-class support for ANSI C in order to support Unix applications.[11] An assembler named SPASM (Simplified PRISM Assembler) was intended for the small amount of assembly code needed for the operating system, and would not have been made generally available in order to dissuade customers from developing non-portable software. Similarly, an implementation of BLISS was developed for internal use only, in order to allow pre-existing VAX/VMS applications to be ported to MICA. MICA would have featured ports or rewrites of many VAX/VMS layered products, including Rdb, VAXset, DECwindows, and most of the compilers available for VAX/VMS.[16]

Throughout the PRISM period, DEC was involved in a major debate over the future direction of the company. As newer workstations were introduced, the performance benefit of the VAX was constantly eroded, and the price/performance ratio completely undermined. Different groups within the company debated how to best respond. Some advocated moving the VAX into the high-end, abandoning the low-end to the workstations. This led to the VAX 9000 program, which was referred to internally as the "IBM killer". Others suggested moving into the workstation market using a commodity processor. Still others suggested re-implementing the VAX on a RISC processor.[3]

This led to considerable problems with turf wars between the various groups. Competition between the divisions delayed the architecture review, which wasn't closed until 1986. Work on associated support chips, the memory management unit and floating point unit, were later interrupted by yet another debate on whether or not the design should be 32- or 64-bit. The MicroPrism design was not finalized until April 1988.[3]

Frustrated with the growing number of losses to cheaper faster competitive machines, independently, a small group outside of Central Engineering, focused on workstations and UNIX/Ultrix, entertained the idea of using an off-the-shelf RISC processor to build a new family of workstations. The group carried out due diligence, eventually choosing the MIPS R2000. This group acquired a development machine and prototyped a port of Ultrix to the system. From the initial meetings with MIPS to a prototype machine took only 90 days, with full production able to start by January 1989, resulting in the DECstation 3100 and family. At a meeting reviewing the various projects in July 1988, the company decided to cancel Prism, and continue with the MIPS workstations and high-end VAX products. Dave Cutler left the company soon after.[3]

Every attempt to produce a faster VAX that could compete with newer workstations eventually failed. The VAX 9000 ran into delays, and by the time it shipped newer Unix workstations had already surpassed it in performance, at a tiny fraction of the cost (or size). Even DEC's own NVAX, a single-chip implementation of the VAX, performed almost as well as the mainframe-sized 9000. Apparently aware of this danger, at the same meeting where Prism was canceled, Ken Olsen asked Bob Supnik to investigate ways that Digital could keep the performance of VAX/VMS systems competitive with RISC-based Unix systems.[17] A group of engineers known as the "Extended VAX" or "EVAX" task force was formed, who originally attempted to produce a RISC-like subset of the VAX architecture.[17][18] When this approach turned out to be a dead end, the group began investigating the feasibility of porting VMS and its applications to a clean-slate RISC architecture. The group decided to adopt the Prism architecture with modifications, which eventually became the Alpha, and began the port of VMS to the new architecture.[19]

When PRISM and MICA were cancelled, Dave Cutler left Digital for Microsoft, where he was put in charge of the development of what became known as Windows NT. Cutler's architecture for NT was heavily inspired by many aspects of MICA.[20][21][22] In addition to the implementation of multiple operating system APIs on top of a common kernel (Win32, OS/2 and POSIX in NT's case) MICA and NT shared the separation of the kernel from the executive,[7] the use of an Object Manager as the abstraction for interfacing with operating system data structures,[23] and support for multithreading and symmetric multiprocessing.[6]

• E-mail with Bob Supnik
• Supnik, Bob (24 February 2008). "MicroPrism". The Computer History Simulation Project.CS1 maint: ref=harv (link)
• Prism documents at bitsavers.org

• Bhandarkar, Dileep P. (1995). Alpha Architecture and Implementations. Digital Press.
• Bhandarkar, D. et al. (1990. "High performance issue orientated architecture". Proceedings of Compcon Spring '90, pp. 153–160.
• Conrad, R. et al. (1989). "A 50 MIPS (peak) 32/64 b microprocessor". ISSCC Digest of Technical Papers, pp. 76–77.