I have been rereading a fascinating discussion about why DEC replaced VAX with Alpha based on talks with people who were there at the time; in a nutshell, in the opinion of the VAX engineers, it was no longer feasible to make VAX performance-competitive with RISC.

I'm not so clear about why it was necessary to develop Alpha instead of continuing with MIPS; DEC had already launched a project to build MIPS workstations, and this would seem to be a reasonably clean RISC architecture that could have delivered high performance at reasonable cost, and would have improved the chances of a single RISC architecture having wide enough industry support to achieve critical mass rather than being outcompeted by x86.

On the other hand, it is true that Alpha did for a while outperform MIPS according to SPEC benchmarks (figures given in the above linked discussion). I'm not clear to what extent this was because of intrinsic qualities of the architecture, versus Alpha having more resources put behind it (development team, fab, TDP?).

Why did DEC go with Alpha instead of MIPS? What characteristics did Alpha have, that led them to believe it would serve them better?

  • 2
    I don't have sources for this so leaving this as comment but I seem to recall that the Alpha was designed from the ground-up to be easy to squeeze performance. They basically did what Intel did to the Pentiums but without worrying about any legacy compatibility with previous architectures. One example of this is how aggressive the Alpha was pipelined
    – slebetman
    Commented Dec 8, 2020 at 7:55
  • 1
    @slebetman Right, the idea behind Alpha was very much similar to the one behind Itanium: Make the hardware vastly simpler to maximize performance, handle all the tricky bits in software instead. Both were "next-gen CPU architectures", and saidly neither succeeded in conquering the world of computing.
    – TooTea
    Commented Dec 8, 2020 at 12:43
  • 1
    @TooTea: Unfortunately, some aspects of the Alpha design made it impossible for it to efficiently process many languages with the expected semantics. For example, popular languages that recognize the existence of multiple threads guarantee that operations on different threads which write adjacent bytes in memory will not interfere with each other. Because offering such a guarantee with byte granularity is much more expensive than offering it only with 32-bit granularity, the original Alpha opted for the latter, requiring that any software that needs to update a single byte use...
    – supercat
    Commented Dec 8, 2020 at 17:16
  • 2
    VMS required processor support for four modes: kernel, executive, supervisor and user. Through the use of PALcode the Alpha processors could support the modes needed by the OS, whether it be OpenVMS, Tru64 Unix or Windows openNT (WoNT). Additional functionality, e.g. for memory management and interlocked operations, could be added in PALcode to support the OS and applications. AFAIK, that flexibility was not available in any other processor at the time.
    – HABO
    Commented Dec 10, 2020 at 3:57
  • 3
    @bobflux: Yes, but processors are still required to correctly handle situations in which e.g. 32 different cores each try to simultaneously access a different byte of the same cache line using ordinary (non-atomic) byte accesses. Performance may be dog slow if every one of the 32 cores continually accesses to its own byte within the cache line, but each core would be required to always see whatever value it last wrote to the cache line without its value getting overwritten by anyone else's operations elsewhere on the cache line.
    – supercat
    Commented Jun 7, 2021 at 23:14

8 Answers 8


DEC needed a 64-bit successor for their VAX. However, VAX was a very CISC architecture at a time when ISA and microarchitecture hadn't been decoupled yet. Turns out DEC had a very hard time trying to scale the VAX to a 64-bit pipelined/superscalar implementation.

MIPS announced the R4000 in the late 80s. It had everything that DEC needed: 64-bit architecture, and the capability of hitting 100Mhz. The R4000 was also supposed to be the target platform for NT, and most PC vendors were expected to migrate to it since x86 was supposed not to scale past the 486.

So it had a lot of momentum and hype going for it.

Digital based its Alpha heavily on the initial architectural specs and sketches of the R4000. And it was kind of a Plan B design.

However, MIPS ended running into problems and the R4000 was late and buggy. This led to MIPS getting into a bad financial position, and they had to be taken over by SGI, who couldn't afford to have their main CPU supplier go under.

Even though the R4000 was the world's 1st 64-bit microprocessor. MIPS was now under the control of a direct competitor of DEC, and their track record didn't inspire much confidence to base DEC's main product line on.

By this time Alpha was ready, so it made no sense for DEC to not consider MIPS any further.

The R4000 showed the way for DEC, since all their previous attempts had ended up being dead ends.


The main thrust of the marketing behind the DEC Alpha was its 64-bit microprocessor architecture. They got there years before potential competitors, including MIPS. At the time DEC was shipping the 64-bit Alpha, MIPS was just beginning to have success with the 32-bit MIPS R3000 being used by SGI.

Given that DEC didn't just need to replace their aging Vax architecture, but also needed to carve out a strong marketing case against competitors like SGI and Sun, being early to market with a 64-bit RISC platform seems a reasonable move. If they just "stuck with MIPS", they would have nothing to differentiate from SGI on the hardware side; whereas SGI itself had a strong differentiator with its 3D graphics hardware. For workstations (not designed for 3D) and servers, Alpha would give DEC a stronger technical and marketing position.

  • 3
    A stronger technical position is not always a stronger marketing position. Commented Dec 9, 2020 at 12:23

and would have improved the chances of a single RISC architecture having wide enough industry support to achieve critical mass rather than being outcompeted by x86.

It's important to remember that in the late 80's and very early 90's when Alpha was being developed, absolutely nobody was worried about x86 dominating high end computing. Not even Intel considered it a likely path forward -- they were working on RISC designs like i860. Defending against x86 is only obvious as a goal in hindsight.

From DEC's perspective, CPU architecture fragmentation was basically a non-issue. Since their founding, they had been a major force in the industry by designing their own architectures. They were selling MIPS, Vax, and even the last new PDP-11 hardware in the early 90's, so the market had room for multiple architectures. Not designing their own next gen ISA would have been like a vineyard giving up on making their own wine. Being permanently dependent on MIPS CPU's in the long term would have been nearly a non starter, especially after seeing how successful designs like SPARC and even ARM were. It was very much an era of bespoke RISC architectures, so it seemed like a golden moment for a company with a history of experience making and supporting new architectures. At the time, high end fabs were much cheaper than they are today, and a company could make a huge profit margin selling CPU's that they manufactured, rather than giving that profit margin to a CPU vendor.

Add that to the fact that MIPS had no immediate path to 64 bit, and Alpha seemed like a huge opportunity.

  • 12
    "would have been like a vineyard giving up on making their own wine". I think you've got the analogy backwards. Should be "would have been like a winery giving up on growing their own grapes."
    – RonJohn
    Commented Dec 8, 2020 at 14:09
  • 1
    "nobody was worried about x86 dominating high end computing" Actually at some point in the late 90s all the popular "Business IT" magazines started to have covers about how IA-64 would take over the world real soon now, leaving dead Alphas, Sparc, PA_RISC, ARM, Motorola, and RS6000 in its wake. It was pretty outrageous. Wads of cash must have been hitting the editorial offices. Commented Dec 8, 2020 at 22:51
  • The future's not ours to see. Lo que sera, sera. Commented Dec 9, 2020 at 12:36
  • 7
    @DavidTonhofer: Well, IA-64 isn't x86 (IA-64 == Itanium, another almost dead architecture), so that doesn't invalidate the original quote. People were worried about other Intel products, but not x86. Commented Dec 9, 2020 at 13:46
  • 1
    @ShadowRanger I aggree! I should have said "nobody was worried about x86" (which was perceived as running out of steam) but (as a counterpoint) people were worried about IA64. Sorry for the unclarity (Amazingly, nobody was ever worried about i860). Commented Dec 9, 2020 at 22:07

DEC's use of MIPS was only ever as basically a stop-gap.

Before they used MIPS, DEC had started work on a project called Prism. It was intended to be their first commercial RISC processor. In June of 1988, however, there was a meeting of senior executives. The PRISM project was producing some interesting technology, but didn't have a chip set available yet (like VAXen, it was going to be a multi-chip design, with FPU separate from the CPU). The executives decided they were too far behind the power curve, so they shut down the PRSIM project, and decided to start using MIPS chips instead.

At the time, this was seen solely as a workstation thing though--something completely different from the VAX. But, it was enough to get one of the executives to ask Robert Supnik to look into the question of whether this new RISC "stuff" could, perhaps, someday become a threat to DEC's VAX systems.

To answer that, Supnik formed what was called the "RISCy VAX" study group. They quickly concluded that yes, RISC could become a legitimate threat to the big machines, not just workstations. In fact, not only could become a threat, bt probably already was enough of a threat that they needed to respond. Further, based on the earlier PRISM work, they felt confident that DEC could produce a RISC processor they could sell.

They then considered a number of approaches to how to make a RISC processor that would run VMS efficiently enough to be successful. Approaches included a stripped-down VAX instruction set, some sort of hybrid RISC/CISC design, etc.

Around then, they considered just porting VMS to some RISC chip (such as MIPS) that was originally intended to run UNIX, but eventually decided that wasn't practical--that porting VMS to such a design would probably add something like 2 years to the schedule.

So, they decided on a pure RISC design, but with some sort of "trap door" to allow them to fairly cleanly add support for some VAX-like features upon which VMS depended (e.g., some parts of how it did its interrupt handling and paging). That resulted in the Alpha's PAL feature, with separate libraries of PALcode to support VMS and OSF1.

As others have mentioned, at the time DEC also saw 32-bit architectures reaching the end of their usefulness, so they decided that the new processor should be a 64-bit design from the beginning--where MIPS not only started out as 32-bits, but didn't have a 64-bit design until well after the Alpha.

They also looked at some of the existing RISC characteristics and decided against them. For example, they saw delay slots as scaling poorly (not obvious how they fit with a multiple-issue, out of order microarchitecture, among other things).

There's quite a bit more to it, of course, but I think that covers most of the "why not MIPS" question though.



Using someone else's processor would fundamentally change the nature of the company, which historically was based on creating computer systems based on DEC-designed processors.

I don't believe DEC was capable of such a radical change.

That's not to pooh-pooh the technical reasons given in other excellent answers here. But historical inertia should not be overlooked.

  • 1
    Nonetheless DEC shipped a lot of MIPS based workstations. Commented Dec 8, 2020 at 16:04
  • 3
    @ChrisStratton In the decade before that, they also shipped PDP-11s built with outside LSI/VLSI technology because they basically were forced to. And as soon as they could, they brought that in-house. DEC always had a vertically-integrated approach.
    – RETRAC
    Commented Dec 8, 2020 at 16:42
  • 3
    As recounted by various sources, MIPS workstations were very much a skunkworks project.
    – dave
    Commented Dec 8, 2020 at 17:51
  • The KL-10 CPU used a processor built by another company to run the microcode that interpreted PDP-10 machine language. Commented Dec 9, 2020 at 12:25
  • 2
    True, but that doesn't result in a commitment to use the same microarchitecture in the future, whereas the choice of user-visible instruction set does.
    – dave
    Commented Dec 9, 2020 at 13:04

It goes deeper than just inventing another ISA, DEC being a hardware company that liked to invent ISAs, etc. As people who have commented (and I can't respond since I'm new here) DEC had MIPS and VAX at the time but they also had a huge installed base of people who were running VMS on those VAXen who needed a path forward.

There was a lot of work that went into Alpha, and the first shot at RISC known as PRISM, to make sure that it could run VMS to give that installed base a path forward as everyone knew that the VAX architecture was running out of ways to make it faster. And even though we were building RISC/Unix workstations and low-end servers out of MIPS products, the word from the software team was that VMS wasn't going to run on MIPS. I often questioned that assumption and was told quite forcefully that there were issues.

And the problem was that installed base of VMS. If the customers were going to take the effort to switch from VAX/VMS to a RISC/Unix offering, a possible large undertaking, the hold that DEC had on them would vanish. Because of the promise of an easy migration from one Unix to another, that customer could be gone forever. And that wasn't a solution that would fly. Thus Alpha was green-lit. And if you are going to invent a new ISA and bring it to market is there really a reason to have two (e.g. keep the MIPS stuff?) of course not, that means designing two of everything and that would have been insane. So MIPS was dead at that point.

And honestly the company had a really hard time convincing customers that they really NEEDED 64-bits but if you were designing a new architecture at that point in time you really had no choice but to make it a 64-bit processor. Systems, at least at the high end, were starting to see memory approaching the 4GB limit with a 32-bit processor. Certainly not on the low end (the VAXstation 4000 Model 60, which was my product, held I think 4 SIMMS that were 32MB and that was considered a LOT of memory at the time) But everyone knew that the 4GB limit of 32-bit addressing was going to be short lived and the engineers gave us 64-bit, both in memory addressing and in arithmetic. But when we were trying to sell the things to people, 64-bits didn't really mean anything to anyone other than the lunatic scientists who wanted to do 64-bit math. (We even tried testing the line that 64-bit addressing didn't matter as much as 34 bit or 36 because memory was getting limited and big applications like transaction processing were memory hogs. It didn't work)

  • I had to port software to unix on alpha, and we found that being 64 bits it was a lot slower than 32 bit systems as our software used lots of pointers and could cache less data in memory with alpha. (However, like many software companies we took advantage of the high discounts to use Alpha servers for file serving etc.) Having to rewrite raster code (with dec paying for the staff cost) to use word rather than byte access gave nice speedups on other systems. Commented Dec 9, 2020 at 23:02
  • 2
    @IanRingrose: If a processor had an addressing mode that could scale a 32-bit object reference in a fashion controlled by the top few bits, that would have allowed a framework like Java or .NET to use 32-bit references to access 4GiB worth of small objects with 16-byte granularity, 16GiB of medium objects with 64-byte granularity, 64GiB of large objects with 256-byte granularity, and 256GiB of huge objects with 1024-byte granularity, allowing an address space much larger than 4GiB without the performance penalty of using 64-bit object references.
    – supercat
    Commented Dec 9, 2020 at 23:47
  • @supercat This was before it was possible to use C++ as all you could depend on when porting software to a system was some sort of C compiler. Commented Dec 10, 2020 at 16:21
  • 1
    @IanRingrose: C would not be a particularly good fit for such an architecture, since it makes no distinction between "reference to start of an object" versus "pointer that can identify any part of an object"; I think much of the antipathy toward the 8086 segmented architecture is from people whose abstraction model is more like that of C than like that of the (much later arriving) Java or .NET. If one manages memory in 16-byte chunks, the 8086 architecture can actually be very efficient, since one can use a 16-bit pointer to identify any 16-byte-aligned object in the address space.
    – supercat
    Commented Dec 10, 2020 at 16:24
  • 1
    @IanRingrose: On the other hand, making optimal use of something like the DEC Alpha would likely require using a language which includes many other features C lacks, such as a means of indicating when a compiler must ensure that operations by different threads on different elements of a byte array don't interfere with each other (which would be expensive, but whose costs would be worthwhile when porting code that relies upon such semantics). Especially given that the C Standard mandates strong semantics for character types, I don't think it's a good fit for the Alpha.
    – supercat
    Commented Dec 10, 2020 at 16:38

DEC as a systems company had lots of experience in creating high-performance memory and i/o systems along with multi CPU clustered systems. All the above requires the ability to extend and modify a CPU including adding additional custom logic.

At the time the only CPU vendor that let other companies change and extend CPU designs was ARM, hence computer companies had to choose between being a "systems integrator" or designing their own CPU.

From the PC market, it had already become clear that system integrators had to give most of their profit to the CPU vendors and could mostly only compete on price with other system integrators.

At the time, it was believed that complex instruction set processors could not complete with RISC - Intel and yet to prove that they could. However, I question if DEC could have afforded the design costs Intel had done so.

(If I recall correctly there was not a 64 bit ARM that DEC could use.)


They wanted an architecture that was capable of supporting OpenVMS, Tru64 UNIX and Windows NT in 64 Bit right from the start. MIPS was not there by the time.

  • 3
    Was NT a factor at the time the decision was made? I know NT 3.1 ran on Alpha (I had one) but I can't recall the sequence of events.
    – dave
    Commented Dec 8, 2020 at 13:34
  • 1
    The importance of OpenVMS in DEC's mindset cannot be overstated. DEC had a huge VAX/VMS user base in Government and Defense sectors, providing a smooth transition was essential to their total systems strategy... just like it had grown the PDP into the VAX.
    – kmarsh
    Commented Dec 8, 2020 at 15:35
  • 6
    We should probably note that OpenVMS is still supported, a couple of decades after DEC ceased to exist.
    – TMN
    Commented Dec 8, 2020 at 16:29
  • 3
    When Alpha was started, the priorities were OpenVMS and DEC OSF/1; NT came later (and wasn’t fully 64-bit on Alpha). Commented Dec 8, 2020 at 21:55
  • 2
    Not OpenVMS. Just plain VMS, until 1991. Commented Dec 9, 2020 at 19:02

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .