Simple CPU

Joseph Bergin
Pace University

A Java CS1 course module introducing:

HashTables, and Library Code
Assembler Language
Concept of a Stack
GUI programming and events
Separation of GUI elements from underlying model of computation.

 

Introduction

In a breadth first course, students should see a bit of assembler language in the first course. This module introduces a simple assembler like language and a simulator in which to execute the programs. The language is that of a simple stack machine. This module could be used to introduce stacks or (perhaps) GUI programming.

Featurs of the language that are required for this are:

Simple if and while statements
Simple Applet and GUI programming
Classes, methods, ...

Student Handouts

The handouts below should be given to the students the class prior to the one in which it will be first discussed with instructions to read and understand it. Students should bring questions with them to the next class. The handout should be on paper (not electronic), so that they need to read it, not execute it. I would give this quite early in the course. They won't understand all of it, perhaps.

SourceCode (The SimpleCPU Class)

SourceCode( The required Prompter Class). The students can ignore the details of this class or not, as the instructor prefers.

Try it. (Or Right/Meta click to down load the html file. You need Sun's Java browser plugin to try it, however.)

Here is a simple object interaction diagram of the eight major objects in the system. See the Follow Up at the bottom for a bit of explanation about the roles of the objects. There is no inheritance visible here, except that SimpleCPU extends Applet.

Lecture Outline

  1. Questions and Answers. Some questions by students and some by instructor. Ask the students which objects talk to which other objects, for example.
  2. Concept of a Stack.
  3. Concepts of Assembler Language such as Memory, Addresses, and the CPU pc.
  4. Some details of this little language and operations on the stack.
  5. Brief discussion of separation of responsibilities. The GUI is encapsulated in the Applet and the Dialog. The computation and its support information is in a separate Model class. The Model class "calls back" to the Applet for display of information.
  6. In class exercise (below).
  7. More discussion.
  8. Assignments and wrapup.

In Class Exercise (team)

Working in the classroom in teams of two, the student can be asked to (among other possibilities)

  1. Figure out what the program in the run method really does.
  2. Write another similar program of the instructor's choosing, perhaps the LCD problem. Students should told to first develop the algorithm in Java and then translate it into this assembler.
  3. Examine the implementation and suggest additional features that would make this language easier to use.

Take Home Exercise(team or individual)

Students are given the code electronically at the end of class so that they can run and modify it.

They can then do any of the following

  1. Add an instruction, swap, that exchanges the top two elements of the stack, leaving.
  2. Add two instructions to multiply and divide the top two elements of the stack. Consider the zero divide problem.
  3. Add additional predicates to the language, similar to pos and zero.
  4. Program with forward and backward jumps using a structured assembly language (since Java has no goto statement).Here is a handout that can help to explain the concepts and the restrictions. You can come up with any convenient exercise for this.
  5. Improve the GUI in simple or complex ways. For example: The Prompter has a design flaw. There is no way for a prompter object to signal its caller that the user has hit the Cancel button. A better design would be to enable it to be called with something like if(prompter.hasLong()) prompter.getLong(); The hasLong method puts up the dialog box.

Follow Up

The Student Handouts are excerpted from some more extensive files. Instructors may obtain copies by contacting me.

This language can be extended a bit to show concurrency in action. It can also serve as the basis of the calculation part of a spreadsheet. In this latter case, programs of this form are stored in spreadsheet cells that are defined by a formula rather than a value. Each of these can serve as an additional course module.

In a course in which GUI elements are not introduced, the exercise can be modified to read and write standard input. It will then need to be an application, rather than an applet. In this case, the prompter is not needed.

Providing more of the flavor of assembler, including jump logic, requires that the program be saved, rather than just written as Java function calls. This is the subject of a later module, in which the fetch-increment-do cycle of a cpu is explored along with pseudo concurrency. The language is very nearly the same for this module.

The simpleCPUModel runs in its own thread so that the modal dialog box doesn't interfere with other operation of the applet. In this version, prompter is inefficient in that it creates a new dialog for each interaction. This should be fixed. (Perhaps by me, and perhaps by your students.)

There are eight main classes here, the SimpleCPUModel, Stack, and Hashtable (model), the Applet, Prompter, and Dialog (view) and two listeners (controller). There are also implicitly some other classes (Thread, Button, TextArea, TextField, Panel) that you might want to ignore. The prompter mediates between the model and the dialog.

Pedagogical Patterns

This is a rather small Larger Than Life overall and is definitely a Toy Box. The in class exercise can be a Student Design Sprint. The Prompter class is both a Tool Box and a Fixer Upper. Some of the take home exercises are Fill in the Blanks. See http://csis.pace.edu/~bergin/PedPat1.2.html, and http://csis.pace.edu/~bergin/fivepedpat.html for further explanation of these patterns.