Introduction

In May 1985, DEC (Digital Equipment Corporation) started the Prism
project to develop RISC technology which would eventually replace their
CISC-based VAX. Why would they do this? In the words of DEC's Gordon Bell, there is
a major revolution in computer technology every then years and VAX first
appeared between 1977-1978

Dave Cutler (working at DEC West in Seattle, a few miles away from Microsoft) headed Prism as well as software sub-projects named
Mica, and
Emerald

March 1988, DEC killed Prism so DEC could continue
building larger VAX systems like Aquarius (now known as the failed VAX
9000). Later they would attempt to port VMS to new systems based upon RISC
chips purchased from MIPS

Summer 1988, Nathan Myhrvold heard about the demise of DEC West then
introduced Bill Gates to Dave Cutler. Bill Gates wanted to build a better
version of Windows which, at that time, was just a GUI overlay running
on top of DOS.

October 1988, Dave Cutler becomes a Microsoft employee and is put in charge of
developing Windows-NT (new technology) which will run on multiple target
platforms (initially: DEC-Alpha, MIPS, and Intel 386. Later inclusions: Intel 486, Intel
Pentium). Dave takes most of his DEC West team with him to Microsoft.

Incredible as it may seem, after the Prism/Emerald/Mica projects were
shutdown, it seems that someone forgot to kill 64-bit RISC hardware
development at DEC's facility in Hudson
Massachusetts. This chip would later surface and be given the name
DEC Alpha

In 1992 DEC finished porting VMS from VAX to Alpha then renamed VMS to
OpenVMS 6.0

Windows-NT 3.51 was popular and the GUI looked like Windows-3.1 and Windows-3.11

Windows-NT 4.0 was even better and looked like Windows-95

Windows-NT 5.0 was released as Windows-2000 and, at the time, was the
most stable OS ever released by Microsoft

Windows-2000 and portions of Windows-ME (millennial edition) merged to
become Windows-XP (experience)

A commercial version with SMP support was released called Windows 2003
Server Edition

Bill Gates, who is known for not making mistakes in business, maintained
two product lines at Microsoft which competed against each other (this
gamble must have cost Microsoft a small fortune but the gamble paid off).

Windows-95, Windows-98, and Windows-ME were designed by the
Microsofties (original Microsoft employees)

Windows-NT, the NTFS file system, Windows-2000, and Windows-XP were
designed by the DECies.

The products designed by the DECies slowly took over the
functionality of the Microsofty products as the two lines merged.

Definitions and Notes

Definition

Notes

DEC PRISM

name of a new DEC hardware architecture after four DEC projects were
rolled into one

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.

quote: Digital brainstormed the next-generation reduced
instruction-set computing (RISC) technology as the successor to
the VAX complex instruction-set computing (CISC) architecture.
This was known as "PRISM" and combined research in high-speed
and streamlined architectures with the so-called Hudson RISC
32-bit projects led by Richard Witek, Dave Cutler, and others. A
prototype was released in August 1985. PRISM's Epicode would
later resurface in the Alpha architecture as programmed array
logic (PAL) code.

cancelled by DEC in July-1988 after it was decided to switch to
RISC processors from MIPS

A high performance, highly available database machine built out
of the QUARTZ database software and MICA subset operating system
running on ROCK systems

Mica

Multipersonality operating system named Mica (project codenames
were rocks-and-minerals). There'd be a base OS API that contained
any function needed by any operating system personality. Environment
subsystems would present the "personality" (i.e., APIs, execution
environment) of VMS, Unix, and anything else DEC wanted. Environment
subsystems would be in user-mode server processes, though it wasn't
going to be a full-blown u-kernel like Mach. Sounds like any other
system you've used?

quote from April 1989: Some time next year, Shannon said, DEC
will bring out a VMS shell that will sit on the Ultrix software.
That package, code-named Mica, will allow selected VAX/VMS
applications to run on Ultrix, he said.

Emerald

code name of the first Mica OS implementation to port VMS onto
PRISM
(quote from April 1989:
http://findarticles.com/p/articles/mi_m0SMG/is_n5_v9/ai_7242480/
Digital has already developed a hybrid operating system called
Emerald, sources say. Terry Shannon, director of the DEC Advisory
Service at International Data Corp., Framingham, Mass., said Emerald
"runs emulations of both Ultrix and VMS." )

Seattle's current official nickname is the "Emerald City", the
result of a contest held in the early 1980s

Some sources state that Emerald was the first iteration of Mica

Some sources state that Emerald was a revival of the cancelled
Mica project with the objective of porting VMS to MIPS (which was
called ULTRIX)

According to
Charlie Matco, Emerald was also attempting to port
VMS to Intel's IA32 (80386, 80486, Pentium)

GEM

So-called "DEC languages" targeted at Alpha and Itanium are based
upon the "GEM Optimizing Compiler
System". GEM is a project code-name rather than an acronym. Everything
coming out of DEC in those days had names like GEM, Opal, PRISM,
Mica, Emerald etc.

PRISM/Mica/Emerald Links:

Excerpt from: Transition from VAX to Prism, MIPS, and Alpha: Losing momentumNext, 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.

Question: Is is possible that PRISM was killed but Alpha was still alive
and Ken Olsen didn't know it?
Answer: Yes

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 DECAnd 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)

<QUOTE>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."<QUOTE>

Showstopper! is a vivid account of the creation of Microsoft Windows
NT, perhaps the most complex software project ever undertaken. It is
also a portrait of David Cutler, NT's brilliant and, at times,
brutally aggressive chief architect.

Cutler surely ranks as one of
the most impressive software engineers the field has ever produced.
After leading the team that created the VMS operating system for
Digital's VAX computer line--an accomplishment that most would
regard as a lifetime achievement--he went on to conceive and lead
the grueling multi-year project that ultimately produced Windows NT.
Both admired and feared by his team, Cutler would let nothing stand
in the way of realizing his design and often clashed with his
programmers, senior Microsoft management, and even Gates himself.
Yet no matter how involved he became in managing his 100-programmer
team, he continued to immerse himself in every technical detail of
the project and write critical portions of the code himself.

Showstopper! is also a fascinating look at programmer and managerial
culture behind the Microsoft facade. The portraits of the men and
women who created NT not only reveal the brilliance of their work
but the crushing stress and the dislocating effects that new wealth
had on their lives. For some team members, the NT project ultimately
destroyed their marriages, friendships, and virtually every human
relationship outside of work. Showstopper! also reveals the
uncertainties, false starts, and blind alleys that dogged the
project as Microsoft repositioned NT from an improved OS/2 to
something that would ultimately challenge both OS/2 and Unix for the
title of the world's most powerful operating system.

"Terry Shannon" channels "Charlie Matco"

Note: "Charlie Matco" is one of the pseudonyms of
industry insider, Terry Shannon

"Darren Peacock" <daz005@hotmail.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

GEM Links:

So-called "DEC languages" targeted at Alpha and Itanium
platforms are based
upon the "GEM Optimizing Compiler
System". GEM is a project code-name rather than an acronym. Everything
coming out of DEC in those days had names like GEM, Opal, PRISM,
Mica, Emerald, etc.

The other day, I posted something in
comp.lang.fortran in response to
a post asking for a new feature in the Intel Fortran compiler. I suggested
that the best thing to do was to submit an issue to Intel Premier Support
asking for the feature since the more customers who ask for a feature,
the easier job the Fortran project manager has in justifying it. This
prompted a startled reply from someone who thought that I
was the Intel Fortran project manager. "Heck no," I replied,
"I'm not even the most senior engineer on the project!" Well, really,
I'm not on the compiler project itself anymore, but I still sit and
work with those who are. Yes, I started my Fortran career at DEC in
1978, but there are others on the team who have been at it longer.

Stan Whitlock, now he IS the Intel Fortran project
manager, as well as our Fortran standards committee representative.
He joined the DEC FORTRAN-10 (for the PDP-10) engineering team in 1976.
Stan later worked on Fortran for the DECsystem 20, VAX APL, and then
rejoined the DEC Fortran team when the short-lived MIPS-based DECstation
line was introduced. He's led the Fortran team ever since, through the
years of Alpha, Digital Visual Fortran and now Intel Fortran. But wait,
there's more...

Dave Eklund joined DEC in 1975 doing support for DEC FORTRAN-10,
but support also meant bug fixing and eventually development. He stayed
with the DEC 36-bit systems and then joined Stan on DEC Fortran, so
he's been doing Fortran continuously for 31 years now.

And then there's Rich Grove. Rich started with DEC back in 1971 on
PDP-11 Fortran. Rich was later the project leader for VAX-11 FORTRAN-IV-PLUS,
to give it it's full name, and he interviewed me for the job I eventually
landed on the VAX Fortran project. Rich later became the project leader
for DEC's GEM code generator and optimizer, which powered the DEC compilers
for MIPS, Alpha and IA-32 (with Digital Visual Fortran.). When Rich
joined Intel, he was named an "Intel Fellow", an extremely senior position
in the company, with the role of "Compiler Architect". While Rich doesn't
work daily on Fortran, he sits just a couple of offices down from us
and keeps Fortran in mind as he helps shape the future of Intel compilers.

I should also mention Peter Karam, another Fortran compiler developer
who has been with the project since he started in 1980. Peter tried
being a manager for a while, but soon found that his heart was in development
so that's where he returned and what he does today.

As you can see, there's a core of dedicated engineers who have guided
a set of Fortran implementations for more than three and a half decades,
starting with DEC, through the couple of years of Compaq, and now Intel.
(We missed HP, which bought Compaq shortly after we joined Intel, which
was a bit more than five years ago.) Of course, there's more to the
project than just these folks, including many developers who have worked
on compilers for 20 years or more (and some young whippersnappers, too.)

I once told a group of customers about our long Fortran heritage
and that we were "a bunch of old farts". One of the group replied, "That's
good - Fortran needs old farts."

Excerpt From Page 354: A case might
be made that RISC ventures could have failed , absent advances
in compilers which made their pipelines perform adequately in
spite of the timing problems with slower load/store instructions
versus faster register-to-register instructions. Otherwise, it
has been argued, the relatively greater "power" of CISC
instructions combined with some pipelining possibilities would
have continued to hold sway since more of the simpler RISC
instructions are needed to solve comparable application
problems.

NSR Comment
(2013-07): I suppose it could be said that it was a lack of
advances in compiler technology which prevented EPIC and VLIW
from taking off the way RISC did previously.

Excerpt From Page 355: MIPS, in
particular, became known for its compiler technology as well as
for its processor architectures. MIPS pursued an approach to
compiler systems involving language-specific "front ends" that
covert programs into one common intermediate encoded form. A
common "back end" analyzes and optimizes that intermediate
expression of the program and then generates actual machine
instructions. A compiler system composed of such front and back
ends can be modified effectively, on the one hand as language
standards change or as another language is supported, and on the
other hand as new hardware implementations require different
optimizations.

Digital Equipment Corporation
developed its well-respected GEM compiler technology at a time
when its line of VAX systems (CISC) was complemented by the line
of MIPS-workstations and servers (RISC), and the Alpha
architecture was soon coming. This GEM technology made it
possible to offer compatible language compilers for both VAX and
Alpha systems, thus facilitating migration of customer
applications from the 32-bit era to 64-bit systems, especially
those for the OpenVMS programming environment.

The
GEM compiler design, like the MIPS system, includes the concept
of a compact, universal intermediate representation. In the GEM
system, a universal optimizer independent of any particular
programming language or hardware considerations operates upon
the intermediate code . Other preliminary optimizations occur
through the operation if the appropriate language-specific front
end. Specific requirements of a particular operating system and
the target hardware are accommodated at the back end when
machine instructions, data storage, and linkage pointers are
formulated.

Compilers sometimes provide control
over the types of optimizations that they can perform. Those
optimizations may include not only generally applicable
techniques such as unrolling loops, but also the deliberate use
of special instructions that are implemented in hardware on some
systems or in software on others. The dilemma in the case of
commercial software is whether to distribute a "one size fits
all" version, or many versions, or one version optimized for a
particular implementation (i.e. model) of a computer system. The
GEM compiler system provides for such implementation-based
tuning.

NSR Comment
(2013-07): The next paragraph discuses a benchmark
program called COM_X which is written as optimally as possible
in Fortran, Pascal, and C.

On page 358 we can see a
3-column table of Alpha machine language output generated by the
compilers with optimization disabled. FORTRAN is the largest;
Pascal is medium while C is the smallest.

On page 362 we
can see a 3-column table of Alpha machine language output
generated by the compilers with optimization enabled. The
FORTRAN column contains 48 instructions, the Pascal column
contains 37 instructions, while the C column contains these 2
instructions:

MOV 1, R0

RET R26

Supporting docs

Note: in the past decade I have noticed PRISM/Mica/Emerald documents dropping
off the net. It is for that reason alone that I started copying specific
high-quality pages here.

Extracted Document 1

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:

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,depends uponinstruction type

Fixed,doesn't depend uponinstruction type

Instruction set

Large,adapted forprogrammer's needs

Medium,adapted for processor'sexecution convenience

Memory access

Allowed for differentkinds of instructions

Allowed for load/storeinstructions only

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".

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

Extracted Document 3

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.

Background

PRISM

Friction and cancellation

Note

References

Background

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.

PRISM

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.

Note

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. ...

quote-1: DEC had been at the leading edge of RISC development. There
were several projects inside DEC between 1982 and 1985, which researched
the RISC area. One was the Titan project was begun as
the initial project of the Western Research Laboratory (DECwest) in Palo
Alto (California), supervised by Forest Baskett in April of 1982. By
December 1985 they had a complete system running UNIX. A second was
SAFE (Streamline Architecture For Fast Execution),
supervised by Alan Kotok and David Orbits, HR-32
(Hudson RISC 32-bit), located at DEC's factory in Hudson
(Massachusetts), supervised by Richard Witek and Daniel Dobberpuhl.
Finally there was the CASCADE project at DECwest in
Bellevue run by Dave Cutler. Eventually DEC decided to unite on a single
architecture and the PRISM project was born in 1985.
This was to be DEC’s RISC system that would run both UNIX and VMS with
Cutler working on the operating system codenamed Mica.
The team tasked with developing it were:- Dave Cutler, Dave Orbits, Rich
Witek, Dileep Bhandarkar, and Wayne Cardoza.

quote-2: According to Bhandarkar DEC had the
rights to develop their own chips and extend the MIPS architecture. This
would have enabled DEC to port VMS to it, however internal politics
prevented this. Meanwhile the decision was taken to close the PRISM
project in July 1988 even though they had developed it as far as the
silicon stage. This decision was taken primarily due to DEC’s financial
situation. It was a decision that led to Dave Cutler resigning and
immediately joining Microsoft with a number of his team and developing
Windows NT which closely resembled VMS and Mica. Much of the technology
they had been involved with in DEC was transferred into the architecture
and code of Windows NT. Ironically, a few months later, Olsen started
the project that led to the Alpha at the same time, using the
accumulated knowledge and many of the people from the PRISM project. Had
he taken this decision earlier, Cutler would have stayed and NT would
not be the same.