The Elements of Computing Systems: Building a Modern Computer from First Principles (54 page)

BOOK: The Elements of Computing Systems: Building a Modern Computer from First Principles
6.34Mb size Format: txt, pdf, ePub
clear-breakpoints:
Clears all the previously defined breakpoints.
built-in-chip
method argument(s):
External implementations of built-in chips can expose methods that perform chip-specific operations. The syntax of the allowable method calls varies from one built-in chip to another and is documented next.
B.2.4 Variables and Methods of Built-In Chips
The logic of a chip can be implemented by either an HDL program or by a high-level programming language, in which case the chip is said to be “built-in” and “externally implemented.” External implementations of built-in chips can facilitate access to the chip’s state via the syntax
chip Name
[
var Name
], where
var Name
is an implementation-specific variable that should be documented in the chip API. The APIs of all the built-in chips supplied with the book (as part of the Hack computer platform) are shown in figure B.3.
For example, consider the command set RAM16K[1017] 15. If RAM16K is the currently simulated chip or an internal part of the currently simulated chip, this command will set its memory location number 1017 to the 2’s complement binary value of 15. Further, since the built-in RAM16K chip happens to have GUI side effects, the new value will also be displayed in the chip’s visual image.
If a built-in chip maintains a single-valued internal state, the current value of the state can be accessed through the notation
chip Name
[ ]. If the internal state is a vector, the notation
chip Name
[
i
] is used. For example, when simulating the built-in Register chip, one can write script commands like set Register[] 135. This command sets the internal state of the chip to the 2’s complement binary value of 135; in the next time unit, the Register chip will commit to this value and its output will start emitting it.
Figure B.3
API of all the built-in chips supplied with the book.
 
Built-in chips can also expose implementation-specific methods that extend the simulator’s commands repertoire. For example, in the Hack computer, programs reside in an instruction memory unit implemented by a chip named ROM32K. Before one runs a machine language program on this computer, one must first load a program into this chip. In order to facilitate this service, our built-in implementation of ROM32K features a load
file
name method, referring to a text file that, hopefully, contains machine language instructions. This chip-specific method can be accessed by a test script via commands like ROM32K load Myprog.hack. In the chip set supplied with the book, this is the only method supported by any of the built-in chips.
B.2.5 Ending Example
We end this section with a relatively complex test script, designed to test the topmost Computer chip of the Hack platform. One way to test the Computer chip is to load a machine language program into it and monitor selected values as the computer executes the program, one instruction at a time. For example, we wrote a program that (hopefully) computes the maximum of RAM[0] and RAM[1] and writes the result to RAM[2]. The machine language version of this program is stored in the text file Max.hack. Note that at the very low level in which we operate, if such a program does not run properly it may be either because the program is buggy, or the hardware is buggy (and, for completeness, it may also be that the test script or the hardware simulator are buggy). For simplicity, let us assume that everything is error-free, except, possibly, for the tested Computer chip.
To test the Computer chip using the Max.hack program, we wrote a test script called ComputerMax.tst. This script loads Computer.hdl into the hardware simulator and then loads the Max.hack program into its ROM32K chip part. A reasonable way to check if the chip works properly is as follows: put some values in RAM[0] and RAM[1], reset the computer, run the clock, and inspect RAM[2]. This, in a nutshell, is what the script in figure B.4 is designed to do.
How can we tell that fourteen clock cycles are sufficient for executing this program? This can be found by trial and error, starting with a large value and watching the computer’s outputs stabilizing after a while, or by analyzing the run-time behavior of the currently loaded program.
B.2.6 Default Script
The simulator’s GUI buttons (single step, run, stop, reset) don’t control the loaded chip. Rather, they control the progression of the loaded script, which controls the loaded chip’s operation. Thus, there is a question of what to do if the user has loaded a chip directly into the simulator without loading a script first. In such cases, the simulator uses the following default script:
B.3 Testing Machine Language Programs on the CPU Emulator
The CPU emulator supplied with the book is designed for testing and simulating the execution of binary programs on the Hack computer platform described in chapter 5. The tested programs can be written in either the native Hack code or the assembly language described in chapter 4. In the latter case, the simulator translates the loaded code into binary on the fly, as part of the “load program” operation.
Figure B.4
Testing the topmost Computer chip.
 
As a convention, a script that tests a machine language program Xxx.hack or Xxx.asm is called Xxx.tst. As usual, the simulation involves four files: the test script itself (Xxx.tst), the tested program (Xxx.hack or Xxx.asm), an optional output file (Xxx.out) and an optional compare file (Xxx.cmp). All these files must reside in the same directory. This directory can be conveniently named xxx. For more information about file structure and recommended usage, see section B.1.
B.3.1 Example
Consider the multiplication program Mult.hack, designed to effect RAM[2] = RAM[0]*RAM[1]. A reasonable way to test this program is to put some values in RAM[0] and RAM[1], run the program, and inspect RAM[2]. This logic is carried out in figure B.5.
Figure B.5
Testing a machine language program on the CPU emulator.
 
B.3.2 Variables
The CPU emulator, which is hardware-specific, recognizes a set of variables related to internal components of the Hack platform. In particular, scripting commands running on the CPU emulator can access the following elements:
A:
value of the address register (unsigned 15-bit);
D:
value of the data register (16-bit);
PC:
value of the Program Counter register (unsigned 15-bit);
RAM[i]:
value of RAM location
i
(16-bit);
time:
Number of time units (also called clock cycles, or ticktocks) that elapsed since the simulation started (read-only).
B.3.3 Commands
The CPU emulator supports all the commands described in section B.2.3, except for the following changes:
load
program
: Here program is either Xxx.hack or Xxx.asm. This command loads a machine language program (to be tested) into the simulated instruction memory. If the program is written in assembly, it is translated into binary on the fly.
eval:
Not applicable;
built-in-chip
method argument(s):
Not applicable;
ticktock:
This command is used instead of tick and tock. Each ticktock advances the clock one time unit (cycle).
B.3.4 Default Script
The CPU emulator’s GUI buttons (single step, run, stop, reset) don’t control the loaded program. Rather, they control the progression of the loaded script, which controls the program’s operation. Thus, there is a question of what to do if the user has loaded a program directly into the CPU emulator without loading a script first. In such cases, the emulator uses the following default script:
B.4 Testing VM Programs on the VM Emulator
Chapters 7-8 describe a virtual machine model and specify a VM implementation on the Hack platform. The VM emulator supplied with the book is an alternative VM implementation that uses Java to run VM programs, visualize their operations, and display the states of the effected virtual memory segments.
Recall that a VM program consists of one or more .vm files. Thus, the simulation of a VM program involves four elements: the test script (Xxx.tst), the tested program (a single Xxx.vm file or an Xxx directory containing one or more .vm files), an optional output file (Xxx.out) and an optional compare file (Xxx.cmp). All these files must reside in the same directory, which can be conveniently named xxx. For more information about file structure and recommended usage, see section B.1. Chapter 7 provides essential information about the virtual machine architecture, without which the discussion below will not make much sense.

Other books

Bad In Boots: Colt's Choice by Patrice Michelle
Violet Tendencies by Jaye Wells
Swept Away by Susan Kiernan-Lewis
1635: A Parcel of Rogues - eARC by Eric Flint, Andrew Dennis
The Penny Dreadfuls MEGAPACK™ by Oscar Wilde, Mary Wollstonecraft Shelley, Thomas Peckett Prest, Arthur Conan Doyle, Robert Louis Stevenson
An Apocalyptic Need by Sam Cheever
Who Loves Her? by Taylor Storm
Chasing Rainbows by Linda Oaks