206 IEEE TRANSACTIONS ON EDUCATION, VOL. 33, NO. 2, MAY 1990

The Dehydrated Vax-A Paradigm for Teaching

Abstract-To carry electrical engineering students from their initial view of a computer as a terminal which understands Fortran to a solid view of what a computing engine does and how to build one, we have found it very effective to include a short, intense section on Assembly- language programing. The section emphasizes the connection between high-level language programming constructs and machine architec- ture. To meet our needs for effective material coverge in a five-week segment of the overall two-quarter course, we have reduced the enor- mous VAX instruction set to what looks rather like a RISC instruction set of 16 instructions. The instructions selected force full awareness of the details of machine performance and of dynamic memory access and control. By keeping the tool-set small, we have time to concentrate on data structures, internal representations, connections between the HLL and the Assembly language expression thereof, and, finally and most importantly, on the hardware structures which must underlie compu- tational activity.

INTRODUCTION NY group of courses which comprise a disciplinary A curriculum faces a chicken-or-egg conundrum in

trying to provide the students with an overview of their discipline while they are down in the trenches learning the details of their trade. Waiting until the details coalesce to a picture of the whole often loses many of the poorer stu- dents and frustrates practically all of them. On the other hand, it is difficult in most subject matter to provide an effective sense of the whole prior to developing the pieces from which the whole is constructed.

Counter examples do exist. They arise where one can do before one fully comprehends. One learns to walk and understands walking long before the recognition that there are mechanics to walking; one learns to drive and under- stands driving long before the recognition that a second law sets lower limits to the cost of doing it. In some sense, those of us who teach computer engineering now have a similar “natural” advantage in that most students are “computer literate” before they appear in their first com- puter engineering course. This paper describes a method that we have used to take advantage of that overview to motivate and enhance our pair of introductory computer engineering courses. This new approach differs from the more conventional bottom-up approach in that we move rather quickly from top-to-bottom and then assemble the pieces necessary to build our way back up to the top. Our

Manuscript received August 26, 1988, revised April 24, 1989. The authors are with the Department of Electrical and Computer Engi-

IEEE Log Number 9034655. neering, Northeastern University, Boston, MA 021 15.

results from the first year of trying this new methodology show far better understanding and appreciation of the con- structs of computer engineering and a real sense of how one designs computing machines.

It is our observation that most of our students enter the camputer engineering part of the electrical engineering curriculum viewing computers as terminals which under- stand Pascal and Fortran. Many of the students have rea- sonably well developed skills in using one or another high- level language (HLL), but very few indeed make any con- nection between HLL statements and declarations and some specific allocation of machine resources. Were we to launch immediately into a course in logic and continue with a course in elementary computer architecture-es- sentially what most computer engineering texts do and what we have done in the past-we would find that few if any of our students made any connection between their HLL knowledge and what we were trying to do.

An obvious alternative is to have a course in Assembly language in between the HLL course and the logic course. This might solve our particular problem, but it is a large investment in a topic of limited utility and one that will inevitably push out some other early course of argu- ably far greater importance to the whole curriculum. It is our view that the principal utility of Assembly language is the perspective that it gives the students on HLL’s, on computing engines and on the connection between them. Viewing Assembly language in this light, we come to the following conclusions:

1) Assembly language is an intrinsic part of the intro- duction to computer engineering.

2) One should present assembly language in such a way as to emphasize: its reltionship to HLL’s; a user’s view of machine architecture; arithmetic and logical primi- tives; data structures and operations; program structure and operations.

3) While some skill in writing Assembly language sub- routines will inevitably derive from the exercises, great competence in writing assembly code is definitely not an objective.

After one finishes the section on Assembly language, the obvious engineering question is: “Now how do we build such a machine?” Once we reach that point in class, we stop with Assembly language and start with hardware. Our design objective was to complete the Assembly-lan- guage unit in five weeks. In that period, we assigned three

0018-9359/90/0500-0206$01 .OO O 1990 IEEE

FELDMAN AND VAI: DEHYDRATED VAX 207

programming assignments of progressive difficulty, where the assignment was accepted as complete only after pass- ing a reasonably thorough acceptance test. Three other topics provided the units which completed the two-quarter course. These were: number systems and binary represen- tations of data; logic circuits; and the design of simple processing machines.

What we had to do to achieve the two objectives stated above, along with fitting all of this material within the tight confines of our two-quarter sequence of conven- tional introduction to computer engineering topics, was to create a rather special computational environment for the assembly language portion. For reasons that will be evi- dent immediately below, we named our creation the de- hydrated VAX.

RISC INSTRUCTION SETS AS A TEACHING TOOL Reduced-instruction-set computers (RISC’s) [ 11, [2]

have been widely touted as better computing engines be- cause, if one may give a one-line reason, their stream- lined design allows more rapid execution of the code or- dinarily generated by HLLs. In general, RISC designs tend to have:

a simple set of primitive data types; a simple but effective set of addressing formats; a short but complete set of instructions; instructions that do not have side effects; instructions which accomplish a single, atomic ma-

This list suggests a very strong although unintentional connection between RISC instruction sets and the needs we have expounded above for an Assembly language par- adigm for educational purposes. The first three items sim- ply reduce the number of items that must be presented, but without emasculating the language which results. The last two effectively bring the computing machine right out into the open. If you want to add two numbers that are in memory, you do not use an instruction that calls upon a hidden subroutine in microcode. You program the steps yourself-bring in the two variables to registers (two in- structions), you add them to a destination register (one instruction), and finally, you put the result back in mem- ory (one instruction).

The most direct route to the computational environment that we espouse would be a RISC machine. For example, we could have MIPS, HP Spectrum, or IBM PC/RT com- puters and proceed directly with them as our environmenr. We could, but we do not. Our computing resources for this project comprised VAXs (8650 and 785 in a cluster), 68 000-based Sun workstations, and IBM PC’s. The 8086/ 88-based machines were totally unsuitable. They are so full of little hooks and “gotchas” that they would be nothing but a thicket of discontent for our application. However, between the 68 000 and VAX, there is little inherent difference that would be important in this appli- cation. Both provided seamless memory, a general reg- ister set, and the instructions, data forms, and addressing

chine operation.

modes that we wanted. We selected the VAX for several reasons.

We have good access to it-plenty of directly con- nected terminals and phone lines for remote access;

the VAX/VMS screen debugger is powerful, reveal- ing and relatively easy to use;

under VMS, we would have a well coordinated set of HLL’s, an assembler and a linker as well as the ability to share files between instructor and students;

under VMS, the instructor can have group privileges (GRPPRV) that permit him/her or the grader to gather and test files, put the results back automatically in a student’s files, and to communicate efficiently with all of the stu- dents in the group either individually or en masse. With 150 students in the course at one moment, ease of access and efficiency in grading is a nontrivial issue;

the VAX is almost universally available in industry, so we would be increasing the students’ effectiveness and marketability by making them more VAX-literate.

These reasons were important but not entirely compel- ling. We are seriously considering shifting to 68 000- based machines (Apple Macintoshes) as soon as our pub- lic Mac resources are adequate to the load. Good screen debuggers and effective compilers, assemblers and linkers exist for the Mac along with its famous ease of use. We would lose the enormous advantages of GRPPRV on a central file system, but we would gain several items which are external to the specific needs of this course.

Our advanced computer engineering courses are based on the 68 000 chip, so all of our ECE students must learn 68 000 assembly code sooner or later;

many students own Macs, so a Mac-based course would permit them to do assignments in a convenient and familiar environment; furthermore, for students who own such a machine, their understanding of and effectiveness in using their computer of choice would be greatly en- hanced;

Accordingly, while the paradigm we present below is VAX-based, it is easily transportable to any general-reg- ister machine.

REDUCING THE VAX

Instructions

What we did was to extract a very small subset of the vast panoply of instructions available on the machine. There are, arguably, in excess of 300 instructions on the VAX. We chose the 16 shown in the condensed program- ming guide (Fig. 1). When one combines these with the addressing modes shown on the guide, they form with two exceptions instructions that are not only easily compre- hended-a first goal-but also instructions which stand in one-to-one correspondence with the internal operations of a conventional computer-our principal objective. The reason for the two exceptions is that the instruction subset must permit linking the procedures and functions written in Assembly language to ordinary HLL programs. This

208 IEEE TRANSACTIONS ON EDUCATION, VOL. 33. NO. 2, MAY 1990

CONDENSED PROGRAMMING GUIDE - - Jmwuakm MOVL a , b ; M e R or R e M moves a longword MOVB a , b ; M = R moves a byte to memory M O V W a , b ; M e R moves a word to memory CVTBLa,b ; R e M sign extends a byte CVTWLa,b ; R e M sign extends a word - J M P a ;PC a BRxx d ;PC e PC+ d

;if xx is true.

CALLS #n, a ;PC a; AP

RET ;points at parameter list which begins with #n, new F P = SP. ;PC c= RA (return address), FP and AP restored as ;before CALLS, stack cleared of parameter list.

SUBL3 a, b, c CMPL a, b

BICL3 a, b, c BISL3 a, b, c XORL3 a, b, c ASHL x, a, c

; c = b + a ; c e b-a ; sets flags according to results of a-b, but does not put the result ; itselfanywhere. Note the reversal of the order compared to SUBL3. ; c e a n b note the complement ; c e a u b ; c = a @ b ; arithmetic shift of x places

Jlu2dem ootatlon descrlDtlon 5 register Rx where 0 5 x I 15. The MACRO assembler also understands

the "names" of 4 of the registers (12..15) as AP,FP,SP, and PC.

0-3 literall #sN where s is the radix specifier (AX,AD,AO or "B) (default AD) 8 immediate

A,C,E base-

and N is a digit in that radix. Literals are used when 63>3M.

NNNN is added to the contents of Rx to form the address. For simple indirection, set N to 0.

sN(Rx) displacement

4 index sN(Rx)[Ril the contents of Ri are multiplied by the number of bytes in the operand (4,2 or 1 in our case) and added to the base- displacement address as above.

Fig. 1.

forced us to use CALLS and RET, two of the most CISC- like instructions in the VAX panoply. These two instruc- tions have proved to be a constant source of confusion to the students, but the appealing alternative of using JSB would be completely incompatible with the HLL calls. Constructing CALLS and RET out of the other RISC-like instructions is too arcane to be seriously considered.

The data types like the instruction set are restricted to the elemental integer forms. We limited ourselves to bytes, words (2 bytes) and longwords (4 bytes). We de- liberately left out floating-point formats so that they could be brought in as exercises at a proper point. The fact that the VAX does not use the IEEE format provided an op- portunity for writing assembly emulators for the hardware functions.

Since the HLL's use bytes, words and longwords, we

were obliged to support all three. However, we adopted the typical RISC and PDP-11 paradigm of always sign- extending to the full register width upon loading the da- tum into register. For that reason, we included CVTBL and CVTWL in our set. By always doing register opera- tions in longwords, we were then able to simplify the re- mainder of our instruction set.

Instructions were "made" to do one thing to simplify semantics. For example, MOVL in the VAX can move a longword from memory to memory, register to register, memory to register or register to memory. We quite ar- bitrarily restricted it to be used as LOAD or STORE would be in a genuine RISC. For R - R operations, which in- ternally use the ALU in the transfer, the students did an:

ADDL3 #O, Rx, Ry ; Ry 0 + Rx

FELDMAN AND VAI: DEHYDRATED VAX 209

We did not play games by hiding the other instruction usage for MOVL, but it was outside acceptble usage for this course. One may certainly argue that adding 0 is an obscure way to move something from register to register, but for a hardware course, it is an explicit description of what is actually done.

Similarly, the clear instruction CLRL is not used either for registers or memory. A student may MOVL #0, Rx or SUBL Rx, Rx, Rx. The first method is a special case of loading a constant from memory. The second case makes explicit the absence of a CLEAR function on the individ- ual registers. As we get into the Assembly language and move past the steepest part of the learning curve, the fact that the VAX designers were making a substantial effort to minimize code size is brought up, comparisons made, and a brief discussion presented on the changing tradeoffs in code size versus processor streamlining. However, this is as far as we take the RISC/CISC argument. The pur- pose of this whole component of the course is to move from HLL to register transfer Language. We do not ex- pect an appreciation of architectural choices from students who have not yet seen the internal workings of any com- puter.

Addressing We use no addressing modes with side effects. For ex-

ample, -(Rx) or (Ry)+ and their related instructions, POP and PUSH, are absent. The students learn to use a static stack pointer and to generate space on the stack themselves. The now obvious movement of the stack as the program progresses provides a marvelous opportunity for explaining both dynamic memory management in an HLL (the heap), which few students of HLL’s understand until they reach this perspective on what goes on in a ma- chine, as well as why one needs both a stack and a heap for normal programming. Here also is the opportunity to drive home what a pointer is and what the difference is between passing parameters by value or by address. While VAX Pascal uses only the latter to maintain compatibility with Fortran, the use of pointers to copies rather than pointers to originals brings up the issue in full force and establishes a good base for understanding both the VAX method and the more direct and normal method of param- eter-passing .

CALLS and RET As we comment above, we are stuck with CALLS and

RET. Since they are the standard pair used for calling subroutines in HLL’s on the VAX, and since we are em- phasizing the connection between what machines do and what HLL’s ask for, we use Pascal for our test and driver programs and make our Assembly languge subroutines subscribe to all of the VAX standards for handshaking in subroutine calls. In the beginning, the assigned routine was the lowest level routine, but later, we reused an ear- lier Assembly language routine as a call in the assign- ment. In this way, the students got to look at a call from both perspectives. Both finctions and procedures were il-

lustrated. We did not use the VAX built-in register mask on the CALLS/RET pair. First, we would not have used those instructions at all if we could have avoided it, and second, we felt that it was important at this stage to em- phasize the saving and restoring of registers. In the first two assignments, we found that many students ignored this requirement. Since we tested for it, their programs failed on testing. Having to make it work is a wonderful dose of reality.

Progressive Assignments The three assignments comprised: I ) String Scan: We attempted to make the assignments

sustain a uniform level of difficulty. Accordingly, the as- signments had to increase in challenge as the students’ capabilities developed. Our students came into this sec- tion of the course already prepared with binary integer arithmetic and the idea of representing characters and numbers in various formats. This made it easy to explain the idea of a string and to have the first assignment be searching for a character in a string. The assignment proved arduous for many of the students because of gen- eral unfamiliarity and because a great many simple details must be mastered all at one time. They were given a week and a half to complete it the first time. They were entitled to one free beta test if they requested it before the due date. After that all tests were scored. On each of the first two problems, a student could receive a maximum score of five. For every test where the program was not fully functional, one point was deducted. To emphasize that done for an engineer means working, a minimum score of two was established if it ever worked and no points were given if a fully functional program was not achieved.

Testing of such a program would routinely call for tests which pushed all of the legitimate “corners” of possible strings. This demands strings of length 0, 1, and greater than 256 (the VAX Pascal string has a word to define its length). One must also have multiple instances of a given character, no instances and instances positioned just be- yond and just inside the ends of the string. Other fairly subtle tests include having a nonzero character just before the string-to be sure that the student used CVTWL rather than MOVL-and also a string of length greater than 32 K to see if the student cleared the upper 16 b in creating the string length. One might argue that a student who did MOVW rather than CVTWL would benefit here, but if that were done without first clearing the register, the test would catch that error as well. Finally, one must test for unmodified return of the contents of registers R2. .RI 1 as required by the VAX standard.

2) Booth s Algorithm: The second assignment in- volved programming Booth’s algorithm for multiplica- tion. The students had had this algorithm in the arithmetic and binary notation section that preceded the assembly language unit. We defined

FUNCTION MULT(n,m:integer; VAR good: boolean) :integer;

210 IEEE TRANSACTIONS ON EDUCATION, VOL. 33, NO. 2, MAY 1990

as overflowing if the result could not be stored in a single longword. That is the standard HLL difinition even though Booth’s algorithm yields a perfectly correct 64 b product for all cases except multiplication by the extremum neg- ative integer (-MAXINT-1 in Pascal). This single prob- lem multiplicand drove home the fact that in finite-regis- ter arithmetic, not all numbers have complements. It also introduced testing for and dealing with exceptions to a general rule. The assignment also introduced masking op- erations, bit tests, shifts and coordinated shifts across two registers.

Since the VAX allows results to be passed through RO and R1, the full extended precision result could be re- turned. We made use of this in the third assignment.

Obviously, there are lots of “corners” to check here, and our test routine did approximately a dozen calls to MULT to cover them all, telling the student which num- bers were being multiplied, what answer was obtained and whether that result was correct. We had been concerned that if the test became known, programs would be de- signed to meet the test rather than meeting full generality. That concern proved unwarranted, and the added assis- tance of having a vector which was known to cause an error helped to minimize student frustration with debug- ging.

3) Floating Point Conventions: After about 2.5 weeks of the five-week unit on Assembly language, we had really completed all of the classroom work we had to cover on the little piece of assembly code and all of the conventions that we were using. In fact, a large part of the last week was devoted to helping with the debugger, talking about reading printouts, and trying to broaden the student’s per- spective on how what they were doing now related to their prior knowledge of HLL’s. At that point, the principal part of the remainder of the classroom time was devoted to floating point-specifically , the IEEE standard single precision convention and the operations of addition and multiplication. The final programming assignment was a project-a more elaborate design assignment which obliged the student to do a proper plan as well as the cod- ing and testing. Students are inevitably resistant to plan- ning ahead, so careful specification of a proper plan was provided and the plan itself was given substantial weight. To be useful as guides for the work of coding and testing, the plans were returned within three days of completion and almost two weeks before the due date for the program itself. The project assignment ran concurrently with the last instructional unit in the course, combinational logic. Many questions got asked in class, but the principal sub- ject matter for those last three weeks not concerned with programming or machine operations.

This extended assignment was to generate FPMUL, a floating point multiplication routine including soft zero, NANs, proper rounding and overflow. The MULT pro- gram previously completed was used to do the product of the significands. (For students still unsuccessful with MULT, a slightly emasculated version was provided by management.) In this way, the students had to do both

sides of the subroutine call. Building a proper call proved to be a problem area for many of the students and well worth while to include and drive home.

The assignment brings in the concepts of packing and unpacking, it showed up the clever thought that underlies the IEEE standard as no pencil and paper presentation can do, and presented a real problem of sufficient length that successful completion made the students feel that they had developed a genuinely functional and useful skill.

For most students, the principal problem with FPMUL proved to be dealing with the 48 b product of the two 24 b significands. Couple this with the enormous range that can arise from the addition of the exponents, with check- ing for overflow, dealing with underflow and finally rounding correctly and at the correct moment in the pro- cess, FPMUL was a handful and then some.

CONCLUSION Measurements on tests, comments from students, and

the greatly increased understanding that we observed when we did the designs of a small, microprogrammed proces- sor and hard-wired Booth’s algorithm multiplier have convinced us that this experiment was a great success. Going down from the HLL to the hardware and then back up from the hardware to a machine was much more edu- cationally effective than building up from the basic logical building blocks. We would list four essential items in achieving the same goals in this or other similar ma- chines. Those comprise the following:

1) Use a small set of operations and addressing modes to reduce the amount of detail with which students must deal. The purpose is definitely not to make skillful As- sembly language programmers but to clarify how HLL statements are carried out by a computer and, conversely, what a computer must be able to do to carry out HLL statements.

2) Choose a subset of the instruction set which as closely as possible reflects the machine primitives. Since this tends to be the set that can be pipelined to execute at one instruction per clock, they are likely to look very much like a RISC machine’s instruction set. Avoid in- structions or addressing modes with side effects, not be- cause they will cause problems in the interrupts or excep- tion handling but because the objective of this exercise is to motivate and to make explicit every action that one is trying to get from the computer.

3) Devote the programming assignments to carrying out tasks which require understanding of the internals of data types and data structures. The objective here is to empha- size how all sorts of different entities can be represented in this uniform sea of bits. 4) After establishing this model of a computer, carry

through by designing a simple processor which can do the instructions that the student has learned. (We substitute JSR for CALLS and RET, but otherwise, we do the entire set.)

A substantial amount of work went into preparing writ- ten materials for the students as well as generating test

FELDMAN AND VAI: DEHYDRATED VAX 21 1

programs and command files to run the tests. We would be happy to share these with anyone who might be inter- ested.

REFERENCES [l] D. A. Patterson and C. A. Sequin, “A VLSI RISC,” COMPUTER,

[ 2 ] W. Stallings, “Reduced instruction set computers,” in Computer Or- vol. 15, no. 9 , pp. 8-21, 1982.

ganization and Archirecrure. New York: Macmillan, 1986, ch. 14.

James M. Feldman (S’58-M’61-SM’75) re- ceived the B.S. degree in physics in 1957, and the M.S.E.E and Ph. D degrees in 1958 and 1960, respectively, all from Carnegie Mellon Univer- sity, Pittsburgh, PA

He is currently Professor of Electrical and Computer Engineering at Northeastern Univer- sity, Boston, MA. He has worked and published in solid-state device theory, computer engineer- ing, and engineering education He has been an Associate Editor for the TRANSACTIONS ON EDU

CATION since 1989.

Dr. Feldman was the recipient of the TRANSACTIONS ON EDUCATION Best Paper Award in 1985.

Man-Kuan Vai (S’84-M’87) was born in Macau in 1958. He received the B. S . degree from Na- tional Taiwan University in 1979, and the M. S . and Ph. D. degrees from Michigan State Univer- sity, East Lansing, in 1985 and 1987, respec- tively, all in electrical engineering.

He joined the Electrical and Computer Engi- neenng Faculty of Northeastern University in 1987, where he is now Assistant Professor of Electncal Engineering His research interests are in VLSI CAD, modeling of high frequency de-

vices, and application of expert systems. Dr. Vai is a member of Tau Beta Pi and Phi Kappa Phi. He received an

Outstanding Academic Achievement Certificate from Michigan State Uni- versity in 1985.