Porting Linux to the DEC Alpha: Infrastructure | Linux Journal

Skip to main content

Porting Linux to the DEC Alpha: Infrastructure

Hardware

by Jim Paradis

on October 1, 1995

Porting an operating system is not<br>trivial. Operating systems are large, complex, asynchronous<br>software systems whose behavior is not always deterministic. In<br>addition, there are numerous development tools, such as compilers,<br>debuggers, and libraries, that programmers generally take for<br>granted but which are not present at the start of the porting<br>project. The porting team must implement these tools and other<br>pieces of infrastructure before the porting work itself can begin.

This article is the first of three describing one such<br>porting effort by a small team of programmers at Digital Equipment<br>Corporation. Our goal was to port the Linux operating system to the<br>Digital Alpha family of microprocessors. These articles concentrate<br>on the initial proof-of-concept port that we did. Although much of<br>our early work has been superseded by Linus Torvalds' own<br>portability work for 1.2, our tale vividly illustrates the type and<br>scale of the tasks involved in an operating system port.

What Got Us into All This?<br>The article by Jon Hall on page 29 describes many of the<br>business-case justifications for our involvement in the Linux<br>porting effort. I will describe the actual events that led to my<br>starting work on the Linux port.<br>First, some background: I work for the Alpha Migration Tools<br>Group, which is an engineering development group within Digital<br>Semiconductor. We were initially chartered near the beginning of<br>the Alpha project to develop automated methods for migrating<br>Digital customers' legacy applications to Alpha-based systems. Our<br>first product was VEST, which translated VAX/VMS binary executables<br>into binaries that could be executed on OpenVMS Alpha. This was<br>soon followed by MX, which translated MIPS Ultrix executables into<br>executables that run on Alpha systems under Digital Unix. Since<br>then, our charter has expanded into other areas of “enabling<br>technology” (technology which enables users to move to Alpha). In<br>addition to producing translators and emulators, we have supplied<br>technology to third-party vendors, and we have participated in the<br>development of compilers and assemblers for Alpha.<br>Our involvement in Linux began at the end of 1993, when we<br>realized that there was no entry-level operating system for<br>Alpha-based systems. While OpenVMS, Digital Unix, and Windows NT<br>were all solid, powerful operating systems in their own right, they<br>were too resource-hungry to run on bare-bones system<br>configurations. In many cases, the smallest<br>usable configuration of a particular system<br>costs at least several thousand US dollars more than the smallest<br>possible configuration. We decided that to<br>compete on the low end with PC-clone systems, we needed to make the<br>lowest-priced system configurations usable. After investigating<br>various alternatives, we decided that Linux had the best<br>combination of price (free), performance (excellent), and support<br>(thousands of eager and competent hackers worldwide, with<br>third-party commercial support starting to appear as well).

Project Goals<br>When putting together the proposal to do the port, I set<br>forth the following goals for the Linux/Alpha project:<br>Price: Linux/Alpha would continue to be free<br>software. All code developed by Digital for Linux/Alpha would be<br>distributed free of charge according to the GNU General Public<br>License. In addition, all tools used to build Linux/Alpha would<br>also be free.

Resource stinginess: Linux/Alpha would be able to<br>run on base configurations of PC-class Alpha systems. My goal was<br>to be able to run in text mode in 8MB of memory and with X-Windows<br>in 16MB. In addition, a completely functional Linux/Alpha system<br>should be able to fit, with room to spare, on a 340MB hard<br>disk.

Performance: Linux/Alpha's performance should be<br>comparable to Digital Unix.

Compatibility: Linux/Alpha should be<br>source-code-compatible with existing Linux applications.

Schedule: We wanted to be able to show a working<br>port as quickly as possible.

Design Decisions<br>The above criteria drove several of the design decisions we<br>made regarding Linux/Alpha. To meet the schedule criterion, we<br>decided to “freeze” our initial code base at the Linux 1.0 level<br>and work from there, not incorporating later changes unless we<br>needed a bug fix. This would minimize perturbations to the code<br>stream (a necessity when you're reaching in and changing virtually<br>the whole universe), and would eliminate the schedule drain of<br>constantly catching up to the latest release. We reasoned that once<br>we got a working kernel, we could then make use of what we had<br>learned to catch up to the most current version.<br>The scheduling criterion also drove our decision to make our<br>initial port a 32-bit (as opposed to a 64-bit) implementation. The<br>major difference between the two involves the C programming model<br>used. Intel Linux uses a “32-bit”...