Excerpt from: Transition from VAX to Prism, MIPS, and Alpha: Losing momentum
Next, I think what really got DEC into the most significant trouble was the way it dealt with the transition from to RISC and to a 64-bit address. Dave Cutler had an architecture called Prism that he had designed at the Seattle lab. That was all done, the manuals were done, people were working on chips, and the program was going along well. Meanwhile, MIPS came to DEC and said: “Gee, you’re not there with RISC or your one chip VAXen, you need a RISC machine for your workstations. Why don’t you build a workstation on RISC?” And DEC did, introduced it, and said: “Oh well, we’ll stay with MIPS.” Then they killed the Prism project and Mr. Cutler left. They killed it, but Ken didn’t know that it wasn’t dead. It was still alive in the semiconductor group and it sprung up as Alpha. And so that came back several years later. Meanwhile other people within the company were looking at building a fast MIPS architecture machine including a group in Palo Alto which built something called BIPS – a billion instructions per second processor. In fact they have one. They had one about three years ago. So all of those projects never came to market. And that’s why I said when I left the company that you’ve got to get rid of VAX, you’ve got to go open. The companies that I then started and worked with were open systems companies. They were all UNIX. But it was deciding to go to Alpha or deciding to do Prism, then killing Prism and going to MIPS, and then coming back to Alpha and killing MIPS again. DEC could have survived any of those decisions. It could have stayed with Prism, got it out there a year earlier, and been significant in the marketplace. It could have switched to MIPS, and I think that would have probably been the best strategy. But coming in late, having to build these very fancy FAB facilities to get the performance was really costly. And today, there is no way I see that DEC can afford to be a semiconductor supplier or microprocessor supplier when they have to build their own, use their own, FAB facilities. So that was a significant error in judgment and decision making. On the other hand, the world is better off because Dave Cutler went to Microsoft and built NT for a much larger market.
Excerpt from Page 216 of DEC is Dead, Long Live DEC
I organized Alpha as a program with me as program manager. This had never worked before in Digital; it had been tried many times, never worked. You may remember the old saying that Digital ran by the golden rule, which was, "he that has the gold makes the rules." Yet the Alpha Program was a team of maybe a half dozen people with never more than a million and a half bucks to speak of. But the time was right to get people aligned around a common effort at engineering.
Excerpt from Page 217 of DEC is Dead, Long Live DEC
And we really did run Alpha as a program. It never resided centrally in any organization, it was never really owned by any VP. It evolved from this core of 6 or eight people to spanning about 105 to 110 projects coordinated by the project team. It outlasted Ken and a bunch of organizational changes and all kinds of chaos in the first layoffs. When we shipped Alpha, we shipped a new architecture, a new chip, four systems, three operating systems, 30 products with field training and the whole works, the the end of '92. It was kind of a defining experience for me (Bob Supnik, interview by Edgar Schein, 2001)
|Cutler's office at DECwest||Bellevue, Washington|
|Gates's office at Microsoft||Redmond, Washington|
So, Cutler walked down the street to Microsoft and offered them Mica which became NT. Later DEC sued MS and, in an out of court settlement, got royalties for the filched technology. Part of the deal included targeting NT (back) onto the Alpha platform. "BTW, this was not an usual procedure at DEC. Many employees left the company with intellectual property from a cancelled project under their arm, with the understanding that if they made it a commercial success then DEC would come back knocking on the door for for royalties."
Note: "Charlie Matco" is one of the pseudonyms of industry insider, Terry Shannon
"Darren Peacock" <email@example.com> wrote in message http://groups.google.com/groups?selm=FsEq6.10155%240N3.67186%40news-server.bigpond.net.au... > Cant remember the detail but back in 1988-89 there was a project in Digital > to do just that .. > My memory is fuzzy but it was called Emerald or Gem .. > It was descibed as VMS on Intel. > > But the initial downsizing then , the project was halted. Funny to see the > following 24 months some of the members end up in a small word processing > company called Microsoft. > Well, I dragged Charlie Matco away from his usual pursuits of wine, women, and rumourmongering and persuaded him to come clean on this matter. There was in fact a DEC project called EMERALD back in the late 1980s. Its goal: to boldly send VMS where it had not gone before... into IA32-land. EMERALD was scuttled right around the same time the PRISM RISC project was killed (late March 1988). Prototype PRISM processors existed at the time, but apparently there were Big Delays with the complementary MICA operating system. MICA was, simply stated, a reimplementation of VMS for the PRISM RISC architecture. Dave Cutler flew the coop right after Ken Olsen pulled the plug on PRISM/MICA. Word has it that a lot of the MICA code rose from the dead when Windows NT was born. Separately, there was a midnight project to port VMS to the Mach kernel. The project was done (half-baked, actually) at Carnegie Mellon University IIRC. Some of the incomplete code--which may well have a few facets of Emerald embedded in it--is said to be floating around somewhere. And that's all I got from Charlie. Heck, he started mumbling some stuff about OZIX, MERLIN, QUARTZ, CHEYENNE, and other cryptic codewords from days gone by. Wish he'd be a tad more forward-looking and spill the beans about MARVEL... and the system a generation beyond MARVEL. cheers, Matco's Handler
Original Title: The PRISM Project. The Alpha Project.
The PRISM Project
In the beginning of 1980's, DEC was on the paramount of its financial strength mostly because of high revenues related to growing constantly sales of VAX hardware and software. Of course, nothing lasts forever, and it was obvious that some day VAX would have to leave the market in favour of a more sophisticated and flexible architecture as it was happening with PDP-11. Those days many companies started to pay more and more attention to RISC-based concepts and implementations, so DEC had no intention to ignore that trend. There were several development teams inside of DEC between 1982 and 1985 which researched actively over the RISC arena:
* Titan, a high-speed design developed at Western Research Laboratory (DECwest) in Palo Alto (California, the USA) and supervised by Forest Baskett, since 1982;
* SAFE (Streamline Architecture for Fast Execution), a project supervised by Alan Kotok and David Orbits, since 1983;
* HR-32 (Hudson RISC 32-bit), developed at the semiconductor factory of DEC in Hudson (Massachusetts, the USA) and supervised by Richard Witek and Daniel Dobberpuhl, since 1984;
* CASCADE, a project by David Cutler in Seattle (Washington, the USA), since 1984.
In 1985, after Cutler's initiative on creating a so-called corporate RISC plan, all 4 projects were merged into a single one called PRISM (PaRallel Instruction Set Machine), and the first draft for a new RISC processor was released in August of 1985. To mention, DEC participated in development of the MIPS R3000 processor those days and even initiated creation of Advanced Computing Environment consortium to promote the MIPS architecture.
No wonder that the new processor inherited many features of the MIPS architecture, though the differences were also obvious. All instructions were fixed-length at 32 bits with the upper 6 and the lower 5 ones presenting an instruction code and the remaining 21 were reserved for immediate data or addressing needs. There were 64 primary 32-bit general-purpose registers defined (MIPS required 32), 16 additional 64-bit vector registers and 3 control registers for vector operations: two 7-bit (vector length and vector count) and one 64-bit (vector mask). There was no processor state register, thus a result of two scalar operands compared was written into a general-purpose register, but a result of two vector operands compared — into the vector mask. There was no built-in floating-point unit. A set of special instructions called Epicode (Extended processor instruction code) was maintained in software through loadable microcode to facilitate handling of special tasks required for a particular environment or operating system given and not supported by the standard instruction set otherwise. Later, this function was implemented in the Alpha architecture under the name of PALcode (Privileged Architecture Library code).
In 1988, when the project was still in progress, top managers of DEC decided to close it considering any further support as a waste of resources. Protesting against that decision, Cutler resigned and went to Microsoft to supervise a department developing Windows NT (called OS/2 3.0 those days).
In the beginning of 1989, DEC presented first RISC-powered workstations of its own, DECstation 3100 with a 32-bit MIPS R2000 inside clocked at 16MHz, and DECstation 2100 with the same processor but clocked at 12MHz. Both machines were running Ultrix OS and were priced rather inexpensively. For instance, it took about 8000 USD (1990) for a DECstation 2100 configured regularly.
The Alpha Project
In 1989, the aging VAX architecture was hardly able to compete with RISC architectures of the 2nd generation such as MIPS and SPARC. It was obvious that the next generation of RISC hardware would leave not so many chances for VAX to survive. In the middle of 1989, DEC's engineers received a task to create a competitive RISC architecture with a long-term potential, but carrying a minimal set of incompatibilities with VAX at the same time. That was because VAX/VMS and all accompanying applications had to be ported to the new architecture which was also defined to be 64-bit right from the start since competitors were about to release their 64-bit solutions. A development group was created with Richard Witek and Richard Sites involved as the chief architects.
The Alpha architecture was mentioned officially for the first time on the 25th of February 1992 during a conference in Tokyo. In addition, most important features of the new architecture were listed within a concise overview for comp.arch, a USENET conference. It was also mentioned that "Alpha" was an internal code-name and an official name had to be provided later. The new processor was of a "clean" 64-bit RISC design to execute fixed-length instructions of 32 bits each. It accommodated 32 64-bit integer registers, operated with 43-bit virtual address space which could be expanded for up to 64 bits in future hardware implementations. Like VAX, it preferred little-endian byte order (i. e. when the least significant byte of a register occupies the lowest memory address if stored; was promoted by Intel in contrary to big-endian byte order, introduced by Motorola and employed by most processor architectures of those days, when the most significant byte of a register occupies the lowest memory address if stored). A mathematical co-processor was built into the core together with 32 64-bit floating-point registers which utilised random access order unlike primitive stack access order implemented in Intel x87 co-processors. The total lifetime of the new architecture was estimated in no less than 25 years.
The instruction set was simplified to facilitate pipelining actions as much as possible and consisted of 5 groups:
* integer instructions;
* floating-point instructions;
* branch and compare instructions;
* load and store instructions;
* PALcode instructions.
To mention, there was no hardware support for integer divide instructions because they would be the most computationally-expensive integer ones and thus badly pipelineable, so they were just emulated. It was an acceptable solution because integer divide was used relatively not so often in real life, especially considering that shift instructions were able to satisfy many integer divide and multiply calculations.
Alpha architecture was a real RISC in contrary to different x86 microarchitectures of the past and present starting with NexGen 586, Intel P6 and AMD K6. In fact, they were RISC on the level of processor functional units only. The conceptual difference between RISC (Reduced Instruction Set Computing) and CISC (Complex Instruction Set Computing) was (and still is) within a few moments:
Feature CISC RISC Instruction length Variable,
doesn't depend upon
Instruction set Large,
adapted for processor's
Memory access Allowed for different
kinds of instructions
Allowed for load/store
Note: This table applies to general purpose processors only because DSPs and other embedded ASICs are much different. For instance, their instruction sets are small typically because of high level of specialisation.
The processor was supposed to be launched in production at a very high core frequency — 150MHz — which was planned to be increased for up to 200MHz while utilising the same engineering limits. It appeared to be possible because of a successful architecture as well as because engineers who developed the processor rejected to involve automatic design systems and did all work just manually. The project entered manufacturing stage and was reorganised into a regular division of DEC soon after.
Because of DEC marketing department's efforts the new architecture was called AXP (or Alpha AXP), though still not known for sure what exactly this misunderstanding meant. Quite possible that nothing at all. In the past, DEC had legal problems with its VAX brand because there was another pretending company, a manufacturer of vacuum cleaners, and the conflict was taken to court that time. By the way, it was also motivated that sales of DEC equipment suffered because of the other company's reasonable slogan, "Nothing sucks like a Vax!" After all, a joke showed up saying that AXP meant "Almost eXactly PRISM".
Title: The Death of Alpha on NT (Windows-NT ran on Alpha???) - A Web Exclusive from Windows IT Pro August 27, 1999
Alpha on Windows NT is dead. As far as NT goes, it’s an Intel world.
Last week, Compaq announced that it was laying off more than 100 of its Alpha/NT employees in its DECwest facility located near the Microsoft campus. This group of developers was tasked with making Alpha on NT a technical reality. Citing Compaq's decision and the strength of Intel's architecture and systems, Microsoft says it will discontinue development of future 32-bit and 64-bit Alpha products across its existing product line.
Now, for the rest of the story...
History The Alpha on NT story has its roots back to the inception of NT. Dave Cutler, NT’s creator, was working on a new OS, code-named "Mica," for Digital Equipment. Digital intended Mica to be a successor to VMS and based it closely on VMS (thus, NT's strong roots in VMS). The Mica team worked at a Seattle-based location called DECwest, an office started by Cutler in the early 80s when he was working on Digital’s MicroVAX I project.
For some reason, Digital killed the Mica project. Seizing the opportunity, Microsoft picked up Dave Cutler and his Mica team and funded the continuation of the Mica project within Microsoft. A few years later, Windows NT was born. Digital, however, suspected that NT was actually Mica reborn and hired an OS specialist to determine the similarities. According to inside sources, many portions of NT’s code and even the comments were identical to Mica. As a result, Digital sued Microsoft. Microsoft and Digital settled out of court and the result was the Digital/Microsoft Alliance.
As part of the alliance, Microsoft promised to support the Alpha processor on NT and to ensure that Microsoft’s BackOffice products (i.e., SQL Server, Exchange Server, Internet Information Server—IIS) would be fully compatible and made available at the same time as their Intel equivalents. Digital added more than 100 engineers to DECWest, tasked with making Alpha on NT a technical reality. As part of the agreement, Digital (now Compaq) and Microsoft would have a perpetual cross-license of NT-related technology including full access to the source code.
What was NOT promised in the alliance was support for Microsoft’s Office, developer tools, or any other desktop products. If Digital wanted its Alpha chip to achieve application parity with Intel, Digital would need to fund the marketing and development efforts to the tune of millions of dollars each year. Digital did an OK job of marketing Alpha technology, creating a 32-bit Intel emulator called FX!32, attracting third-party software vendors, getting outside manufacturers to fabricate Alpha chips, and providing a line of Alpha-based workstations and servers. Other than a few isolated events such as Scalability Day or WinHEC, Microsoft did not market Alpha on NT.
When Compaq purchased Digital, many people feared that the Alpha chip would die. However, Compaq pledged renewed support for Alpha by announcing that future versions of its Tandem Himalaya computers would move from a MIPS chip to an Alpha chip. In addition, Digital UNIX (Tru64), NT, and VMS would continue to use and improve Alpha technology. Compaq recently added Alpha support to Linux.
The 64-bit question, however, remained: Can the Alpha ever achieve the economies of scale to compete with Intel or should it be positioned as a low-volume, high-margin chip for high-end computing? The answer is clear. It would be a high-end, low-volume chip, which is great for Himalaya, Tru64, and OpenVMS, but didn’t fit the high-volume NT market. As a result, Alpha on NT marketing was nonexistent. Any Alpha/NT momentum created by Digital ended abruptly.
Linux Originally, NT supported four CPU types: MIPS, Alpha, PowerPC, and Intel. Over time, the marketing and development resources required to pursue the NT market reduced the market to NT/Intel. Today, Linux supports many CPU types, including Alpha. Is this a win for open-source vs. closed-source development? Will the open-source community continue to support Alpha over the next 4 years, even if volumes don’t support it? Perhaps there are enough open-source Linux developers who will keep Alpha/Linux alive for years in spite of market dynamics—purely for the love of developing and supporting the Linux community. Time will tell.
The Future Today, Dave Cutler’s team is using Alpha-based systems to develop 64-bit NT. At WinHEC (April 99), Microsoft was able to boot 64-bit NT on an Alpha-based computer. However, at the current pace of development, Intel might deliver its 64-bit chip (Merced) by the time 64-bit NT is ready. If this happens, the fact that Alpha was first would offer little competitive advantage. Microsoft will position the 64-bit NT Server as a high-end, low-volume solution for those applications that need maximum scalability—e.g., a large SQL Server database that needs gigabytes of RAM for caching. Would the 64-bit version of NT perform significantly better on the Alpha vs. Merced for this type of application? If not, then being first and fastest would NOT overcome Intel’s competitive advantages: compatibility and cost. In the past, Compaq would position VMS, True64, or a Himalaya system for a highly scalable database application. Will Compaq position 64-bit NT against VMS, Tru64, or Himalaya? Not likely. Could a 64-bit Alpha Windows 2000 Professional (Win2K Pro) workstation save Alpha on NT? No way. Therefore, Alpha on NT is dead.
Will an Intel-only version of NT fundamentally change NT? "Not likely," says Mark Russinovich, author of the NT Internals column for Windows NT Magazine. "There’s already a significant amount of Intel and Alpha-specific optimization code in the kernel. The hardware abstraction layer (HAL) won’t be affected because it’s still a fundamental part of the OS. I believe Microsoft would want to leave the door open for other chips in the future," says Russinovich.
Support Over the years, I’ve received numerous emails from happy and frustrated users of Alpha on NT. Administrators using one BackOffice application like Exchange Server on an Alpha-based server seemed satisfied with the performance and reliability of their systems. The extra scalability their Alpha systems provided made a huge difference. For Alpha-workstation users, there is the constant frustration of not being able to use the latest version of Microsoft’s developer tools, Office, and other applications. And although FX!32 provided much needed compatibility, many times it did not allow performance of its Intel equivalents, which defeated the original reason why someone would buy an Alpha—speed!
Microsoft and Compaq have stated they plan to continue support for Alpha on NT through Service Pack 6 (SP6) for NT 4.0. This will let existing users get full use out of their systems, but cut them off from Win2K. Other sources such as Aaron Sakovich’s AlphaNT site (http://www.alphant.com) will continue to support Alpha on NT users with the latest news, drivers, applications, and tips.
The Impact of Alpha My heart goes out to the community of loyalists, users, developers, and vendors that have tirelessly supported Alpha on NT over the years. I believe Alpha on NT set a performance bar that motivated Intel to improve its chip offerings much faster than it had in the past. We’ve seen significant performance gains for Intel over the past 2 years—it’s hard to keep up. The gap has closed significantly. The loss of Alpha on NT might slow this process down. The loss also reduces any leverage Microsoft might have had against Intel. All NT eggs are in one basket now, for better or worse. One of these days, the hare might beat the tortoise, but not today.
Editor's Note: For additional reading about Alpha on NT, see the following Windows NT Magazine articles. (To view the articles online, you must be a Windows NT Magazine subscriber.)
"The Performance Curve" by Aaron Sakovich, January 1999 http://www.winntmag.com/Articles/Index.cfm?ArticleID=4686
"Living with Alpha: Finding Help" by Aaron Sakovich, February 1998 http://www.winntmag.com/Articles/Index.cfm?ArticleID=2924
"AlphaPowered" by Mark Smith, August 1997 http://www.winntmag.com/Articles/Index.cfm?ArticleID=26
Original Link: http://www.nationmaster.com/encyclopedia/DEC-PRISM
PRISM was a 32-bit RISC CPU design from Digital Equipment Corporation (DEC). It was the final outcome of a number of DEC-internal research projects from the 1982-85 time-frame, and was at the point of delivering silicon in 1988 when management canceled the project. The next year work on the DEC Alpha started, based heavily on the PRISM design.
In the early 1980s DEC was a huge success, flush with cash and infused with a feeling of invincibility. Projects were started all over the company to chase the "next big thing", with little or no overall direction or managerial oversight.
RISC computing was one of those next big things, and in the period from 1982 to 1985 no less than four attempts were made to create a RISC chip at different 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 fab, intended to be used as a co-processor in VAX machine. The same year Dave Cutler started the CASCADE project at DECwest in Seattle.
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-1986 and was heavily supported by simulations by Pete Benoit on a large VAXcluster.
On the integer side of things, the PRISM was a "me too" design in many ways, and displays a considerable similarity to the MIPS designs. Of the 32-bit instructions, the 6 highest and 5 lowest bits were the instruction, leaving the rest 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. The PRISM and MIPS also lack the register windows that were a hallmark of the "other" design, Berkeley RISC/SPARC.
The PRISM design was notable for several aspects of its instruction set, however. 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. An instruction set, or instruction set architecture (ISA), describes the aspects of a computer architecture visible to a programmer, including the native datatypes, instructions, registers, addressing modes, memory architecture, interrupt and exception handling, and external I/O (if any). ... To meet Wikipedias quality standards, this article or section may require cleanup. ... In computer software, an application binary interface (ABI) describes the low-level interface between an application program and the operating system, between an application and its libraries, or between component parts of the application. ... A vector processor, or array processor, is a CPU design that is able to run mathematical operations on multiple data elements simultaneously. ...
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 fabbing in April 1988. Additionally, Culter led development on a new microkernel-based operating system code-named Mica, which was to offer Unix-like and VMS-like "personalities" on top of a common substrate of services.
Friction and cancellation
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. Others suggested moving into the
workstation market using a commodity processor. Still others suggested re-implementing the VAX on a RISC processor.
This led to considerable problems with corporate immune response and 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.
By this point in time other groups in DEC, fed up with the constant in-fighting and delays, decided to create their own series of workstations based on the MIPS R3000, running a port of their existing Ultrix Unix-like operating system. From the initial meeting to a prototype machine took only 90 days, with full production able to start by January 1989. 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.
Ironically, every attempt to produce a faster VAX that could compete with newer workstations was essentially a failure. 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). Apparently aware of this danger, at the very same meeting where PRISM was canceled, Ken Olsen started a new project to continue exploring a RISC-based VAX. This indirectly led to the formation of the Alpha project the next year.
DEC PRISM should not be confused with Apollo PRISM, which was used in Apollo's DN10000 workstations. Apollo Computer, Inc. ... PRISM (Parallel Reduced Instruction Set Machine) was Apollo Computers high-performance CPU used in their DN10000 series workstations. ...
* E-mail with Bob Supnik