Why did DEC develop Alpha instead of continuing with MIPS?

Question

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?

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

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.

---

References

• IEEE: How DEC Developed Alpha
• Linux Journal: An Interview with DEC

Answer 5

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.

Answer 6

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)

Answer 7

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

Answer 8

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.