An Interview with DEC

The Alpha port of Linux actually started on two fronts, one in the Littleton, Massachusetts offices of Digital Equipment Corporation, and one on a riverboat in New Orleans, Louisiana.

The first front was started by Jim Paradis of Digital Semiconductor’s Alpha Migration Tools group. Jim’s group is responsible for finding innovative new ways of using Alpha processors, and Jim had been looking at several versions of the Unix operating system to determine if there was a possibility of doing a port. Jim had determined that Linux would give an efficient, powerful operating system, and he proceeded to start a 32-bit port of Linux to the Alpha as a test case. Jim believed that a 32-bit version of Linux would be the easiest platform for porting the GNU tools, the X Window System and other applications.

In the meantime, Jon “maddog” Hall was helping to plan for a DECUS event in New Orleans. DECUS is the Digital Equipment Corporation Users’ Society, and the Chairman of the DECUS Unix Special Interest Group (Unix SIG), Kurt Reisler, wanted to bring Linus Torvalds to DECUS to speak about Linux. This was in May of 1994, and V1.0 of the kernel had only recently been released. Kurt was having trouble funding Linus’s trip from Helsinki, so the Digital UNIX Base Product Marketing Team funded the trip. On meeting Linus, maddog was as impressed with the young man as he already was with the operating system he had designed. After DECUS, while riding the riverboat Natchez, the prospect of doing a 64-bit port to the Alpha was broached, and a short time later, an Alpha system was on its way to Helsinki.

About that same time, I found some of the Digital UNIX engineers were using Linux. Through contacts made in the engineering group, I located Jim Paradis and opened up conversations with him. Shortly afterward, a small team of engineers were put together to do further work on the Alpha port of Linux. Through marketing research, I convinced the team that joining their efforts with Linus in doing his 64-bit port was the thing to do. Although the 32-bit port was further along at the time, the 64-bit port was moving fast, and the issues around 32/64-bit porting were not materializing to the extent Jim had expected. Therefore, Jim “packed up” the 32-bit port, and the engineering staff started to attack the 64-bit port along with Linus and several brave volunteers.

When this project started, Linux only ran on Intel x86-based systems. The early days involved a lot of frantic activity tracking Linux kernel releases, and at the same time, porting Linux to the Alpha AXP platforms. The earliest port of Linux to the Alpha AXP was based upon the 32-bit Intel kernel, and in retrospect, maybe we should have been braver and gone straight to 64-bit native AXP support. At that time Linus was working toward exactly this end. His approach was to port the kernel to AXP and run Digital Unix binaries to get a working system. Our approach was to take 32-bit Intel Linux and port that and the rest of the system applications (for example init and bash) to AXP without disturbing their natural 32-bit-ness. We swapped a lot of code with Linus but in the end felt we were not contributing to the mainstream effort—which was always Linus’s codestream. I guess there was just so much to be done that all of the work was useful, but in the end, we switched over to Linus’s 64-bit AXP kernel work and contributed there. Very little of the early work was wasted; the work I did on MILO (the Alpha Linux Miniloader) ported straight over to 64-bit Linux, as did Jay Estabrook’s device driver work and Jim Paradis’s memory management and systems work. The PCI code used in all of Linux’s platforms also comes from that time period. Our first goal was to get a self-hosting Alpha Linux system that did not crash and had working SCSI and Ethernet device drivers. We needed SCSI to support the file system and Ethernet device drivers to support networking. There had to be enough applications to be able to build the Alpha Linux kernel.

In the very early days, there were no other Alpha AXP users besides the three of us in Digital and Linus. Another hardy early contributor was David Mosberger-Tang, who was brave enough to buy an Alpha AXP Noname system and start hacking. The five of us worked hard and the code flowed freely. Our early goal was to have a free distribution of Alpha Linux that could be taken and used by the greater Linux Community. Jim Paradis’s BLADE release contained enough of a system for people to easily get Alpha Linux up and running on their system well enough to start writing code. At the time BLADE came out, there were only two widely available supported Alpha Linux systems, the Jensen (DECPC 150) and the Noname board (so called because any clone vendor could put their name on it). The Noname board was reasonably—although still rather expensively—priced, and quite a few were purchased for running Linux. BLADE got Alpha out to the mainstream Linux community—or, at least, to the braver souls in the Linux community.

Another market research “coup” was the decision to have only one source code tree for the kernel, as was the determination to have the Alpha version of Linux as close to the Intel version as possible. One of the early projects based on this decision was to move away from the Extended Common Object File Format (ECOFF) and to do Executable and Linking Format (ELF) instead. ELF had already been selected for the Intel side, and the Intel version of Linux had to transcend the a.out-to-ELF formats. The ELF project started immediately, and the transition from ECOFF to ELF happened before Alpha Linux rolled into common usage.

Before ELF, the image sizes were enormous since every image was statically linked. When ELF came along, the entire system usage got a whole lot better. The change was particularly dramatic on the DEC Multia/UDB (Universal Desktop Box); you could run X in 32MB of memory and not use any swap space.

The third big marketing decision was that Digital would not sell Linux, but instead allow the existing vendors of Linux systems to supply the distributions and support. This led to the decision to have Digital engineering contribute back in source code (whenever legally possible) everything they had developed for Linux.

At Digital we never saw ourselves as “owning” Linux; Linux cannot be owned or controlled by anything but the worldwide Linux community. Throughout the early days we were essentially playing catch-up with Intel Linux. We were writing code, porting code and running around showing people this neat, new thing. We Digital folks saw (and see) ourselves as part of the wider Linux community. I had not even used Linux before MILO first booted it on an Alpha. Linux is infectious. Our role was, and still is, to be a catalyst to the rest of the Linux world. A good example is the Red Hat Alpha Linux release. We helped make that possible, but it was Red Hat who did the real porting work. They did it because, like us, they believe Alpha AXP is a good Linux platform. Another example of Digital leveraging the larger Linux world is the driver for our TGA (or Zlxpe) graphics adapter. This card had no XFree86 support but was being used in our Windows NT and Digital Unix Alpha systems. Jay Estabrook did a port of XFree86 for that device, and we also released TGA sources to the XFree86 project.

Many might ask why the Alpha port is important. First of all, the Alpha is the world’s fastest single-chip microprocessor. Linus wanted a fast system to show what Linux could do, and the Alpha was a natural choice.

Secondly, the Alpha is a true 64-bit system, with 64-bit integers and a 64-bit virtual address space. This allowed Linus to see what the kernel would require in the way of page tables, etc. On another plane, the large address space of the Alpha allows Linux to be used in research for computing large memory models—particularly interesting in parallel systems and clustering techniques.

Third, the Alpha is a very clean RISC architecture. In the beginning, it was so clean that the Alpha did word accesses only to memory, which forced some of the kernel data structures to be redesigned for efficiency. Later Alpha chips have byte instructions, but this cleanliness of the architecture helped to set the pace for other RISC architectures.

Many folks have taken to the Alpha because they like its technology. Its purity of architecture, speed and natural 64-bit support are very attractive to technologists. There was a lot of interest from the research and academic communities—the combination of an operating system that we already knew and loved, together with falling prices of Alpha-based systems helped sales quite a bit.

Fourth was the fact that Digital was an early adaptor of the PCI bus. Although some early Alpha systems had Turbo-channel buses for backwards compatibility with our older systems, Digital started early in the Alpha system life to provide PCI support, at the same time blending in EISA and ISA support, too. This made it easier to move device drivers from Intel Linux to Alpha Linux, which would probably have been more difficult if the systems had a proprietary bus, such as the Sbus or NuBus.

Alpha Linux has been able to capitalize on two things. Firstly, Alpha PCs with their PCI and ISA buses can use exactly the same devices as Intel PCs. Secondly, the price of an Alpha PC is mostly determined by its component prices and, as the price of the Alpha Linux OS has fallen, Alpha PCs have correspondingly become much cheaper, and thereby, more attractive.

Fifth was the fact that Digital was encouraging clone makers by selling Alpha systems, boards and chips to original equipment manufacturers who wished to make their own configured system boxes. In order to make this as inexpensive and open as possible, the Alpha Linux engineering team chose the Advanced RISC Computing (ARC) console systems (commonly used with Windows NT), and wrote a source-code-available version of the console code (called MILO) as well as a source-code-available version of the privileged architecture library (PAL) code.

But from a general viewpoint, it was important that a 64-bit port be done, and done with a different architecture than Intel. At the time the Alpha port was started, the Linux kernel was highly optimized for the Intel architecture, utilizing more than a little Intel assembly language and Intel architecture tricks in places like context switching, and it was only a 32-bit port. Likewise, the source code tree and the kernel structure were not optimized for various architectures. By porting to the Alpha, the Linux team paved the way for all the other ports to be completed and integrated cleanly.

There is more to Linux than the operating system. Most of the useful functions of Linux are in the system utilities that make the Linux operating system what it is. Bash, X servers and so on, are what the user sees and uses. The kernel is a relatively small (but important) part of the system. As the small but determined group of Alpha Linux users grew, they concentrated on getting more of these system utilities to run. Meanwhile, at Digital we concentrated on supporting the hardware platforms and devices we believed would make good Linux systems. For example, Digital Semiconductor sells a range of PCI network chips under the codename “Tulip” (the 21x4x device range). A lot of Linux device drivers were not particularly portable then, since some had embedded Intel assembly code in them as well as 32 bit-isms. Jim and Jay spent a lot of their time porting working Intel Linux device drivers over to Alpha Linux, ironing out portability issues. maddog was waving the Alpha Linux flag at various trade shows, and in August 1995, we were able to show Alpha Linux running an S3 X server at the Unix Expo. I worked on the Alpha Linux Miniloader, MILO, which is, roughly speaking, LILO on acid. It is a freeware loader that allows Windows NT Alpha boards to boot and run Linux. It uses real Linux device drivers and file systems to get the Linux kernel loaded and running. As soon as Jim and Jay got the device drivers working in Linux, I’d get them working in MILO. MILO lowers the entry price of Alpha Linux as you do not have to pay either the system resource monitor (SRM) console license fee or the Digital Unix license fee to buy a hardware platform that runs Linux. In the spirit of Linux and the Free Software Foundation, MILO is freely available and redistributable code.

At this point the Alpha project is about at parity with the single Intel processors from a functionality standpoint. Work is starting on systematic multi-processing (SMP) for the Alpha, and the things that are missing for the Alpha tend to be missing (for the most part) from the Intel Linux systems as well—applications. The Java port that is being worked on for Alpha Linux will certainly help fill this gap, as will projects like GNUstep and other application environment issues.

Today Linux’s multi-architectural support is very natural. Almost everything a Linux user or system needs can be built for Alpha straight out of the box. Our early aim was to make Alpha Linux an attractive alternative to Intel Linux. With off-the-shelf Linux distributions, most device drivers running happily and a wide choice of supported graphics devices, we have achieved our goals. Along the way we have had fun, made friends and learned new stuff. What is left to do for Alpha AXP Linux? First, we will continue to support our hardware and, as we build new Alpha PC motherboards, we will either port Linux ourselves or make the information available that will allow others to do the port. Second, we will make technical information available to the wider Linux community. The one thing I have learned about the Linux community is that there are a lot of bright and able programmers who only need the right information and some access to the hardware to do an excellent job. Third, we need to make Alpha Linux systems price competitive with Intel Linux systems. When we were first porting Linux, the price differential was very high, but in the last two years, that price gap has closed significantly due to more companies cloning and selling Alpha PC systems in volume. Linux is responsible for a fair proportion of that volume.

We could use some more tuning of the compiler optimization sequences which the gcc compilers generate for the super-scalar Alpha architecture. Likewise, certain math libraries need to be optimized and made available in source code format, not only for the Alpha, but for other ports as well.

We would like to see a virtual porting and certification lab on the Internet, so applications developers who do not have Alpha systems can port and test their applications. This would also be a good idea for some of the other ports, such as SunSPARC, PowerPC, etc.

Testing and benchmarking of Alpha systems running Linux under different load types, creating meaningful benchmark results would also be useful.

Doing real work in large-scale distributed computing with “clusters” of Linux systems would also provide helpful information.

Also needed is a defined set of applications program interfaces (APIs) and application binary interfaces (ABIs) that fit across a variety of Alpha Unix and Linux systems (FreeBSD, netBSD, Linux, Digital UNIX and a variety of other Unix systems) so that commercial application vendors could create shrink-wrapped applications for a larger audience than any one Unix system could attract. Applications tested against the ABI should be able to run on any Alpha Unix/Linux system.

I agree. The future of Linux (all flavours) rests on its ability to attract applications. Whilst the normal engineering set of tools (Emacs, LaTeX, Tk and so on) works quite happily on all of the Linux platforms, Linux needs more of the marketing and presentation tools. It needs a viable desktop environment. That can either be the ability to run Windows applications via Wabi or it can be native applications conforming to some interface specification. The free software world is unfortunately less interested in WYSIWYG applications than in writing operating systems.

One option I find really attractive is the idea that Java applications could run under Linux as well as, if not better than, any other operating system incorporating a Java Machine.

While Digital has allocated four engineers, one product manager and one very over-worked marketing manager to the task, we realize none of this could be possible without the long hours contributed by the Linux community.

We want to help the community move Linux along the path that they feel is the best.