|Authors :||Douglas Harms, Dave Berque|
|Title:||Smaller and Faster is not Always Better: Using Old Hardware to Teach Content and History to Computer Science Students|
|Publication Info:||Ann Arbor, MI: MPublishing, University of Michigan Library
This work is protected by copyright and may be linked to without seeking permission. Permission must be received for subsequent distribution in print or electronically. Please contact firstname.lastname@example.org for more information.
Smaller and Faster is not Always Better: Using Old Hardware to Teach Content and History to Computer Science Students
Douglas Harms, Dave Berque
vol. 4, no. 3, November 2001
Smaller and Faster is not Always Better: Using Old Hardware to Teach Content and History to Computer Science Students
This paper describes our use of old computing devices to reinforce traditional course content in the undergraduate computer science curriculum while simultaneously exposing students to important historical developments in the field. We begin by providing some background about the place of computing history in traditional undergraduate computer science curricula. Next we give several short examples that illustrate the benefits that can be obtained by demonstrating old computing devices to undergraduate computer science students. These examples are followed by a somewhat more detailed case study of our use of a PDP-11/10 to support an hour-long module that we have incorporated into our computer organization course for the past few semesters. The module is designed to reinforce standard concepts such as number systems and two-pass assemblers while at the same time exposing the students to some historical issues. Finally, we describe a fifteen-minute instructional video that we have produced on the topic of developing programs on the PDP/11-10 and report on experiences using the video with students. Links to the video (in Quicktime format) are provided within the paper thereby allowing instructors at other schools to try our approach by showing the video to their students.
The Association for Computing Machinery (ACM) and the Institute of Electrical and Electronics Engineers (IEEE) are the two largest professional organizations dealing with computer science. The ACM/IEEE-CS Joint Curriculum Task Forcexs landmark report, Computing Curricula 1991 [  ], contains recommendations for including historical content in several of the knowledge units which comprise its model curriculum. For example, the knowledge units related to operating systems suggest that students should be exposed to x...operating system development, including historical information about the development of architectural support for changes in software, and the economic and technical forces that drive operating system developmentx [  ]. The ACM and IEEE are in the process of releasing an updated version of their 1991 report. The latest draft of the new document, to be entitled Computing Curricula 2001 [  ] contains similar recommendations. In spite of the legitimacy that these reports lend to including historical issues in the undergraduate computer science curriculum, discussion of such issues has been relatively limited in the education literature. For example, the proceedings of the largest conference on topics related to computer science education, the ACM Special Interest Group on Computer Science Education Technical Symposium, contain a paucity of information dealing with the role of historical issues in the curriculum. In fact, the 1999, 2000, and 2001 symposium proceedings [  ,  ,  ] collectively list only 3 of the 38 xBirds of a Feather Sessionsx as dealing with an historical issue. More dramatically, of 80 workshops, 10 seminars, 44 panels, and 226 papers described in the proceedings, only one deals primarily with historical topics (the single paper on this topic was authored by the current authors [  ]).
Although publications dealing with the relationship between history and computer science education have not been frequent, several other authors have written on this topic. For example, Katz [  ] has outlined concerns about the accuracy of historical topics covered in standard textbooks, while Gal-Ezer and Harel [  ] have pointed out the importance of Computer Science educators being well grounded in the disciplinexs history, and Lee [  ] has illustrated ways in which old technologies such as Napierxs Chessboard Calculator can be used as teaching tools. In the remainder of this paper we follow up on Leexs theme by showing how we have used old computing devices to help teach several instantiations of the standard Computer Organization course. The next section presents several short examples of our approach. In subsequent sections we look at a particular example, namely our use of a 1970's era PDP-11/10 computer in a Computer Organization course, in greater detail. After a brief review of PDP-11/10 history, architecture, and supporting peripherals, we describe how we integrated a short PDP-11/10 demonstration into our Computer Organization course in order to reinforce standard concepts such as number systems, loaders, and two-pass assemblers while simultaneously providing historical perspective. Finally, we describe a fifteen-minute videotape about the PDP-11/10 that we have produced with assistance from our media center. This video makes it possible for instructors at other schools to try our approach without needing access to a PDP-11/10.
.02. A COLLECTION OF SHORT EXAMPLES
The typical undergraduate computer science curriculum gives more attention to topics such as software design and implementation, fundamental algorithms and storage techniques, and underlying mathematical concepts than to issues related to hardware. However, undergraduate computer science majors are typically required to take one course that deals with hardware issues in a significant way. This course is generally called "Computer Organizationx or " Computer Architecturex and common topics include number systems, digital logic, the function of specific components such as the bus, machine language, and assembly language. In addition to covering these standard topics, DePauw's Computer Organization course has some broader goals. These are expressed in the following statement taken from a course outline used in a recent offering of the course: x...students will gain an appreciation for the historical development of technology, and the people who make technological advancements.x Instructors have approached this goal, in part, through a variety of supplemental activities that we present in the remainder of this section. We note that these activities reinforce standard course concepts while simultaneously accomplishing the broader goals noted above.
As a means of achieving the broader goals mentioned above, we have often assigned students to read The Soul of a New Machine [  ], which describes the experiences of the team that designed Data General's Eagle computer (later known as the Eclipse MV/8000) during the 1970's. Students have generally found this true account to be both enjoyable and relevant, and they have participated enthusiastically in the follow-up discussion that is skillfully led by a colleague in the English department. In addition to learning about some of the technical challenges faced by the designers, the students gain some historical context which we believe helps them to better appreciate modern computing systems.
Computer science students are accustomed to being told that the transistor represented a huge improvement over vacuum tubes and mechanical relays. However, very few of the students have ever actually seen a vacuum tube or a mechanical relay and fewer still understand how these devices work. We believe it is difficult for a student to truly understand how a transistor can be an improvement over an earlier device without first having at least a basic understanding of the earlier device in its own right. To address this concern we have sometimes invited a faculty member from the physics department to visit the class in order to explain and demonstrate vacuum tube technology. In addition, one of the authors has constructed a crude AND gate out of mechanical relay style technology, and this device, as shown in Figure 1, is also demonstrated for the class.
Another example of our approach grows out of our discussion of specific components of a computing system such as the bus. Simply defined, a bus is a set of parallel wires in a computing system that connects one component to another. The number of wires on the bus (or the width of the bus) determines how much data can be transferred between two components in a single operation; thus, the bus is an important factor in determining the speed of a computer. Concrete examples often help students, and an instructor might open a modern PC to show students the bus. Unfortunately, as shown in Figure 2, even at a close range the wonders of modern miniaturization make it impossible to see that a bus is a set of wires.
DePauw is fortunate enough to house some artifacts from the ENIAC computer. The ENIAC was designed and built in the mid-1940s and is generally considered to be the worldxs first fully implemented, electronic general-purpose computer. The ENIAC was 80 feet long, weighed 30 tons, contained 18,000 vacuum tubes, consumed 140 kilowatts of power, was a machine 8 feet high, 2 feet deep, 80 feet long, and occupied a 30 x 60 foot room at the Moore School of Engineering at the University of Pennsylvania. Figure 3 is a photograph taken in 1946 of the ENIAC. In this figure the bus can be seen as a set of horizontal xtraysx located about one foot from the bottom of the ENIAC that run the length of the ENIAC.
We have recently taken to illustrating the concept of a bus by showing the students a small piece (approximately eight feet long) of the ENIAC bus. As shown in Figure 4 it is impossible not to be able to tell that the bus is essentially a set of wires.
As a final example we consider a typical discussion of the notion of bits, bytes, files, and directories. Computer science students are accustomed to being told that a bit (binary digit) is a single 0/1 value, a byte is a collection of 8 bits, a file is a sequence of bytes, and a directory stores groups of files. However, none of our students have ever actually seen a physical bit, byte, file, or directory and thus these concepts can be difficult to internalize at first. We help the students to understand these concepts by showing them a paper tape such as the one shown in Figure 5. Holes on the paper tape represent binary ones, and the absence of holes represents zeroes. Each column of paper tape stores one byte (see Figure 5), and an entire paper tape stores a sequence of bytes (i.e., a file); paper tape xfilesx are normally labeled with a handwritten name (i.e., the filename), and a collection of tapes is a directory as shown in Figure 6. One xdeletesx a paper tape file by physically throwing it in the trash can (which, interestingly enough, is recoverable until the custodian empties the trash!). Students often understand an abstract concept (e.g., binary data) better when they have experience with a concrete realization (e.g., holes in a paper tape). These analogies may seem simple, but experience shows that they are helpful to students. Furthermore they help students appreciate the history of computing while simultaneously clarifying technical content.
.03. A MORE DETAILED EXAMPLE: THE PDP-11/10
In this section we consider a more detailed example of the use of old computing devices to support undergraduate computer science education. Specifically we focus on our use of a PDP-11/10, which was introduced in June 1972 and is one of the earliest members of the very successful PDP-11 family of minicomputers. We begin this section with an overview of the PDP-11/10 system from a technical point of view before moving on to discuss our use of the system to teach several offerings of a Computer Organization course.
3.1. PDP-11/10 SYSTEM OVERVIEW
The PDP-11/10 CPU implements the basic instruction set of the architecture, which consists of 59 instructions and twelve addressing modes (register direct, register deferred, auto-increment, auto-decrement, auto-increment deferred, auto-decrement deferred, index, index deferred, immediate, absolute, relative, and relative deferred). Operands are either byte (8-bit) or word (16-bit) values, and the addressing modes permit operands to be in one of eight 16-bit general purpose registers, in memory (possibly accessed via a register), within the instruction itself, or on a stack. Subroutine call/return instructions permit easy implementation of recursive subroutines.
The PDP-11/10 implements a 16-bit address bus, which limits the address space to 64KBytes. Memory is implemented using magnetic core with a 950 nsec cycle time and is byte-addressable with consecutive even/odd addressed bytes addressable as one 16-bit word. The first 512 bytes of memory are reserved for trap and interrupt vectors and the upper 8KBytes of the 64KByte address space is used for memory-mapped I/O device registers. No Memory Management Unit is offered for the PDP-11/10.
All system components (i.e., CPU and I/O devices) connect to and communicate with each other via a single bus called the UNIBUS. A wide variety of UNIBUS peripheral devices are available, including terminals, line printers, card readers/punches, paper-tape readers/punches, magnetic tape units, disk drives, and clocks. (Descriptions of many peripherals available for UNIBUS systems can be found in [  ].) A front panel consisting of several lights and toggle switches is included with the system. (See Figure 7.) This allows an operator to load and examine registers and memory, reset the system, and control execution of a program (start, stop, and single-step).
DEC provided some software with the PDP-11/10. Specifically, the machinexs paper tape software system included an editor, an assembler, several loaders, an online debugger, an I/O executive, and a math package. On disk systems DEC provided a simple disk operating system (DOS), a job-stream processing system (BATCH), and a time-sharing system (RSTS-11). BASIC and FORTRAN were also available.
The PDP-11/10 computer is physically large by todayxs standards, as shown in Figure 8. For example, the 19x x 10.5x x 23x system unit weighs 110 pounds and houses the power supply, CPU (implemented on two 8.5x x 15.75x printed circuit boards consisting of approximately 240 SSI chips), core memory (each 16KByte frame implemented on two 8.5x x 15.75x printed circuit boards and one 8.5x x 10.5x printed circuit board holding the actual core memory), and up to twelve peripheral cards. An entire computer system consists of one or more 22x x 30x x 72x mounting cabinets holding the system unit and peripherals, weighs several hundred pounds, and dissipates several thousand watts of power.
Despite its physical size the PDP-11/10 does not implement several features common on modern computers. For example, the CPU does not implement instructions for integer multiplication, integer division, or floating point operations. (An optional Extended Arithmetic Element (EAE) card implements integer multiplication and division; no floating point processor was offered for this CPU.) There is no processor state (e.g., supervisor vs. user) and thus no method to prevent a program from executing any legal instruction (e.g., HALT) or accessing any memory location (including xsystemx routines and I/O device registers). A detailed description of the PDP-11/10 can be found in [  ].
3.2. USING A ONE DAY PDP-11/10 MODULE TO REINFORCE COURSE CONCETPS: LIVE DEMO APPROACH
Starting with the fall 1998 Semester, the authors have added an additional hour-long xPDP-11/10 Modulex to their offering of the Computer Organization course. Each student attended a one-hour demonstration of the PDP-11/10 in action. The demonstration included a discussion of the historical context of the PDP-11/10, an overview of the PDP-11/10 hardware that included taking the computer apart to show the physical sizes of components such as the CPU and core memory, operation of the front panel to load and execute PDP-11 machine language programs, and the procedure for using the paper tape tools (loaders, ED11 editor, and PAL11 assembler) to develop and execute assembly language programs.
The PDP-11/10 and the associated development environment are obviously archaic and cumbersome compared to contemporary systems. However, we believe that our careful demonstration of selected features of the PDP-11/10 has been of great benefit to our Computer Organization students. The primary benefits to students are summarized below.
Concrete reminders that machine language is fundamentally different from high level languages.
Programming the PDP-11/10 is a very hands-on and physical experience for students: the students help toggle machine language programs into memory using only the switches and lights on the front panel, and data files exist as very physical collections of holes on paper tape. This user interface is very different than the windowing systems they are used to using in other courses and provides a very real sense that theyxre xnot in Kansas anymorex when programming in machine and assembly languages.
Concrete experience with abstract concepts such as bit, byte, file.
The PDP-11/10 presents students with physical representations of binary data. Switches on the front panel are physical representations of binary 0 (switch down) and 1 (switch up); similarly, lights on the front panel represent 0 (light off) and 1 (light on). Finally, as previously discussed in section 2, binary data also has a physical representation on paper tapes. In fact, the paper tapes shown in Figure 5 and Figure 6 are actually from our PDP-11/10.
Concrete experience with binary, octal, and hexadecimal numerals.
Seeing the switches on the front panel of the PDP-11/10 being used to xtogglex a program into memory gives students direct experience with the relationship between octal and binary as well as the advantages of octal over binary. Because octal is used to express 16-bit values in the PDP-11 (for reasons beyond the scope of this paper), the switches and lights on the front panel are organized in groups of three with each group labeled alternately with red and blue coloring (see Figure 7.) Each colored group represents one octal digit, and as students learn about toggling they very quickly understand that octal x5x is represented by xup-down-upx in the switches and xon-off-onx in the lights. This physical representation helps students learn the octal-binary conversion table. Also, students very quickly appreciate the fact that it is much easier to think about and toggle xx than it is to think about and toggle xx.
Experience using loaders.
The PDP-11/10 does not have any ROM and students understand they have to explicitly load every program they need. Using the front panel to toggle a program into memory is the only method of loading a program provided by the PDP-11/10 hardware; after seeing several programs toggled in, students appreciate that this method of loading is only practical for very small programs.
Our PDP-11/10 does not have any disk drives, but instead relies on paper tape as the primary means of external storage. A paper tape is a collection of bytes, and students realize the possibility that a paper tape could represent the memory image of a machine language program. The problem, of course, is getting the data from paper tape into memory. Because the paper tape reader is an I/O device it is possible to write a program that reads the contents of a paper tape and stores it into memory; this program is called a loader. How is the paper tape loader (called the bootstrap loader) loaded into memory? By toggling! Thus, students see the bootstrap loader (which is a 14 word program) toggled into memory, used to load the absolute loader from paper tape (the absolute loader is larger and more robust than the bootstrap loader). Then the students see how the absolute loader is used to load all subsequent paper tapes during the program development life cycle. These tapes include the editor, the assembler, the assembly language source program, and the machine language image. Following this experience with paper tape loaders students easily extend the concept of a loader to other storage devices such as disks. They also appreciate that the initial toggling of the loader can be avoided if the bootstrap loader is burned in ROM and automatically executed when the computer is turned on.
Although we have not done any formal assessment of the effectiveness of this approach, anecdotal evidence indicates the students found the demonstration to be interesting and useful. The paper tape system, the front panel, and the physical size of the computer, particularly compared to the limited computational power of the computer, especially intrigued them.
3.3. USING A PDP-11/10 TO REINFORCE COURSE CONCEPTS: THE VIDEO TAPED APPROACH
Since the PDP-11/10 is almost thirty years old it is difficult to find replacement parts for it, and it is not clear how much longer we will be able to keep it in working order. As a way of preserving our ability to demonstrate the machine to our students, we recently made an instructional video with the help of two students who have taken the Computer Organization course and who also have had courses in television production. The complete video runs for approximately fifteen minutes and focuses on the topic of developing programs on the PDP/11-10 and other similar computers. Links to the complete video can be found in section 4 of this paper. In the remainder of this section we highlight some of the key points of the video, and we include links to two short video clips in as appropriate. Links to the complete video are provided in the next section.
We tried to make the video interesting to our audience in part by constructing a simple story line that unfolds during the video. We begin with a discussion between a modern-day computer science professor and his student during which the student complains about how time consuming it is to write and debug C++ programs. The professor tells the student that things used to be much more tedious in xthe old daysx and he offers to use a use a Holodeck Program to take the student on a trip to see an older computer. The pair enters the Holodeck and with the help of some special effects they find themselves in a 1970 era machine room complete with old line-printer art. In the machine room they encounter a programmer who is humorously dressed in 1970's clothing and who is busily working to write a program on his brand-new PDP-11/10. <holodeck.avi> During the ensuing dialog the professor-student pair asks the 1970's programmer a number of questions about how this machine works. As the questions are answered, the visitors learn how to toggle in the bootstrap loader using the switches on the front panel. Now that the machine is ready to load and execute other programs, the programmer demonstrates how to edit, assemble, save (on paper tape), and execute simple programs. Along the way points are made about a number of issues including the hardware configuration, the use of the octal number system, how bits, bytes, and files are represented on paper tape, the two-pass assembly process, etc. Whenever possible these points are related to concepts that are typically covered in the computer organization course. For example, the notions of bits, bytes, files, filenames, and directories on a paper-tape system are contrasted to their modern day counter parts.
After producing the first version of the videotape we field-tested it with a group of twelve undergraduate computer science students. We asked the students to respond to written questions about the content of the video, and also invited them to participate in a focus group that gave them the opportunity to make suggestions about how the video could be improved. Their answers to our questions confirmed that they had learned a significant amount from the video. For example, the students were able to correctly respond to questions about the process of running programs on the PDP-11/10, and about the role of paper tape in storing files. On the other hand, the students had some constructive criticisms of the video. Most notably, many of the students pointed out that one section of the video moved too quickly, and they urged us to add a summary of the major points covered in that section. Other students suggested that graphical overlays could be used to more clearly point out the different parts of the PDP-11/10. Subsequently we have revised the video in response to these suggestions. For example, a graphical overlay is used to show how the switches on the front panel are grouped together, and how groups of three switches can be used to represent a single octal value.
During the fall semester of 2000 we showed the PDP-11/10 video to the second authorxs Computer Organization class. The class had an enrollment of twenty-four students, and twenty-three of the students were present on the day the video was shown. Each of these students completed a short survey that gave the authors the chance to gather some very preliminary data about the effectiveness of the video (at least from the student viewpoint). The survey asked the students to react to several statements using the following rating scale:
1 = strongly agree
2 = agree somewhat
3 = neutral
4 = disagree somewhat
5 = strongly disagree.
We have not done any statistical analysis of the results, but the scores were generally positive. For example, when asked to react to the statement xThe video was interestingx the mean response was 1.3. When asked to react to the statement xWatching the video was useful because it helped me to understand the history of computers betterx the mean response was 1.7. Similarly, when asked to react to the statement xWatching the video was useful because it helped me to understand one or more concepts we have discussed in class this semesterx the mean response was 1.6. Finally (and thankfully) when asked to react to the statement xWatching the video was a waste of timex the average response was 4.8.
.04. VIDEO DISSEMINATION AND FUTURE WORK
We are interested in learning whether faculty at other institutions will find the video to be useful in their classes. Toward this end, we invite interested faculty to use the video in their classes. The video is available as four Quicktime movies <PDP-pt1.mov> | <PDP-pt2.mov>. Alternatively the video is available in VHS format or on CD from the authors. We welcome comments about the effectiveness of the video as well as suggestions for improvement.
We are also considering making follow up videos that stress other aspects of the PDP-11/10, for example its hardware architecture including core memory and bus. If the original video proves to be successful we may undertake this project in the coming years.
The authors wish to acknowledge DePauw University undergraduate students Matt Farrell and Brian Goad for producing and editing the video described in this paper as part of a course that they took under the direction of Brad Boeke, director of Television Operations at DePauw University.
1. ACM. Proceedings of the 1999 ACM SIGCSE Technical Symposium on Computer Science Education. ACM Press, New Orleans, March 1999.
2. ACM. Proceedings of the 2000 ACM SIGCSE Technical Symposium on Computer Science Education. ACM Press, Austin, Texas, March 2000.
3. ACM. Proceedings of the 2001 ACM SIGCSE Technical Symposium on Computer Science Education. ACM Press, Charlotte, North Carolina, March 2000.
4. ACM/IEEE. ACM/IEEE-CS Joint Curriculum Task Force. Computing Curricula 1991 Report of the ACM/IEEE-CS Joint Curriculum Task Force. ACM Press and IEEE Computer Society Press, 1991.
5. ACM/IEEE. Joint IEEE Computer Society/ACM Task Force on the Year 2001 Model Curricula for Computing. Computing Curricula 2001 (pre-release draft). http://www.computer.org/education/cc2001/index.htm
6. Digital Equipment Corporation. PDP-11 Peripherals Handbook. 1973.
7. Digital Equipment Corporation. PDP-11/05/10/35/40 Processor Handbook. 1973.
8. Gal-Ezer, J., and Harel, D. What (Else) Should CS Educators Know? Communications of the ACM, September 1998, Vol. 41, No. 9, pages 77-84.
9. Harms D., and Berque D. Using a PDP-11/10 to Teach Content and History in Computer Organization Courses, Proceedings of the 2001 ACM SIGCSE Technical Symposium on Computer Science Education. ACM Press, pp. 209-213. Charlotte, North Carolina, March 2000.
10. Katz, K. The Present State of Historical Context in Computer Science Texts: A Concern, SIGCSE Bulletin, December 1995, Vol. 27, No. 4, pages 43-50.
11. Kidder, T. The Soul of a New Machine, Avon Books, New York, 1981.
12. Lee, J. Those Who Forget the Lessons of History are Doomed to Repeat It, Or Why I Study the History of Computing, IEEE Annals of the History of Computing, Vol. 18, No. 2, IEEE Press.