A Microprogramming

Simulator

for

Instructional

Use

J. R. Parker
K. Becker
Department of Computer Science
University of Calgary
2500 U n i v e r s i t y Drive N.W.
Calgary, Alberta, Canada
T2N-IN4
The
of
sor
ate
and
and

teaching of computer a r c h i t e c t u r e at a low level is made difficult by the
complexity
the real systems which are used as examples and tools. This paper d e s c r i b e s a processimulation system which is intended for use at the second and third year
undergradulevel for teaching techniques and concepts in the i m p l e m e n t a t i o n of instruction sets
microprogramming.
The important features of this system are in the
user
interface,
not n e c e s s a r i l y in the actual processor which is simulated.

teaching
too
many details can often be a
student with no grasp of the g e n e r a l i t y of
an
idea
or
its
r e l a t i o n s h i p with other
concepts.

The IEEE C u r r i c u l u m for u n d e r g r a d u a t e
computer engineering [5], and the ACM curriculum for B.Sc. Computer Science degrees
[6,83
both
contain
courses
on computer
architecture
at
the
elementary
level.
Specified as a topic of study is m i c r o p r o gramming and the
implementation
of
computer
instruction
sets.
While the maj.or
d i f f e r e n c e s between discrete logic
implementation
and m i c r o p r o g r a m m e d implementations can be explained in
a
straightforward
way, the details and the 'flavor' of
creating a new instruction in m i c r o c o d e is
not
as easily conveyed. While many modern
machines have m i c r o p r o g r a m m e d
instruction
sets, not all of these possess a w r i t e a b l e
control store,
and
not
all
are
easily
used.
Some m a c h i n e s can be damaged by bad
microcode. Most
machines
with
writeable
control
store
are
complex, and most are
expensive. Thus, it is
not
practical
to
allow the average undergraduate student to
directly
experience
microprogramming
on
such machines.

The apparent a r t i f i c i a l l i t y
of
devices
such
as
the
2900 lies in the fact
that
they
are
marketed
solely
as
a
microprogrammable
chip,
with no resident
instruction set. Thus,
the
microinstructions
take
the
place of normal instructions, as on a CPU chip like the Z80,
and
microprogramming
looks
a lot like assembler programming.
While
microprogramming
actually IS a lot like assembler coding in
some ways, the intent of using a tool such
as
this
in teaching is to u n d e r s c o r e the
differences,
to
allow
the
student
to
explore
the
new
techniques
involved in
m i c r o p r o g r a m m i n g , and to
see
the
consequences on m a c h i n e architecture.
Based on the arguments above, what is
proposed is a software emulation of a simprocessor.
The
plified microprogrammable
processor should be simple enough that its
structure can be understood after
a very
few
lectures
and labs, and yet it should
provide features suitable for i l l u s t r a t i n g
advanced
concepts
in
architecture.
The
students
understand
that
this
is
an
e x p l a n i t o r y device, and not a real system.
Later, with the skills learned on the simplified
system,
the
more complex 'real'
systems may be mastered more quickly.
The
simulator
is
a metaphor for the concepts
that
students
consider
difficult,
and
leaves the actual details for later.

What remains as educational tools
in
area
are
chip sets, such as the AM
this
2900, which are, to first and second
year
undergraduates,
too
complex
and artificial.
An introduction to
a new
concept
should
involve
suitable
metaphors, simplifications, and a b s t r a c t i o n s
to
convey
the
major principles and concepts, rather
than a complete and detailed collection of
facts
which, while real and relevant, are
The result
of
too specific and too many.

Permission to copy without fee all or part of this material is granted
provided that the copies are not made or distributed for direct
commercial advantage, the ACM copyright notice and the title of the
publication and its date appear, and notice is given that copying is by
permission of the Association for Computing Machinery. To copy
otherwise, or to republish, requires a fee and/or specific permission.
© 1984

ACM-O-89791-126-1/84/O02/O069

Microtool is
a
system
of
programs
intented to assist in the teaching of concepts
in
microprogramming
and
computer
architecture. The system provides students
with a facility for writing and
executing
microcode
without the normal c o m p l e x i t i e s
of dealing with an
actual
microprogrammable
CPU
with writable control store. In

$00.75

69

addition, high level debugging
input and output utilities are

used
textbook
was
available
for use in
c o n j u n c t i o n with the system. The reader is
referred
to
this
text
for an e x c e l l e n t
detailed d e s c r i p t i o n of the processor.

tools
and
provided.

Use of this utility
is
expected
to
simplify Junior and Senior level architecture courses, by
providing
a
'hands-on'
demonstration
of many important concepts.
As well, since the system is written in
a
language, it is r e a s o n a b l y
high-level
portable, and cannot harm or even
disrupt
the
processor
on
which it runs. It also
allows large numbers of students to
actually
experience microprogramming, without
incurring a large hardware expense or producing a c o n t e n t i o n problem. Many students
can run the
system
simultaneously
on
a
multiprocessor
(as
opposed
to
a
stand
alone real
system).
This
is
especially
important
at
this time, with class sizes
e x c e e d i n g previous r e a s o n a b l e limits.

Figure I shows
the
major
processor
components,
giving
as
well
the control
points which make up the m i c r o s t o r e
word.
Micro
i n s t r u c t i o n s are 40 bits in length,
and are of two types:
GATE
instructions,
which
move data from a source to a destination, and TEST instructions, which
compare
a bit
constant
against a bit in a
register, and branch
to
a target
micro
address
if
the bits have the same value.
Figure I gives the
format
of
these
two
kinds of instruction.
The micro i n s t r u c t i o n s
are
executed
by the processor in three subcycles, w h i c h
provides a very important temporal separation between parts of a micro instruction.
During the first subcycle, gates I thru 29
may
be
opened, p e r m i t t i n g data t r a n s f e r s
to take place into the adder.
The
second
subcycle
allows
gates
30
thru 37 to be
opened,
which
allows
results
from
the
a d d e r / s h i f t e r to be moved into d e s t i n a t i o n
registers. Finally, subcycle three permits
either
the read or write gates (38 or 39)
to be opened,
implying
that
a read
or
write
operation
will
take place. Parker
[4] gives a table of data t r a n s f e r s possible
in
this
processor, and d e s c r i b e s in
more. detail the function of each gate.

The MicroTool (or uTool) system
consists
of
an
emulator for a h y p o t h e t i c a l
m i c r o p r o g r a m m a b l e CPU, a compiler
for
a
'high level' micro language, and a collection of e x e r c i s e s
which
illustrate
concepts
in
computer architecture. Students
may
write
microprograms
for
the
CPU,
either
as
bit
sequences
or as symbolic
statements, and then
'run'
them
on
the
emulator.
The
processor is, of course, a
simplified and somewhat idealized one,
to
avoid clouding the relevant concepts.

The

Processor
The m i c r o p r o g r a m store,
or,
control
store
contains
256
of
the 40 bit micro
instructions, which means that
eight
bit
m i c r o s t o r e a d d r e s s e s are needed.
The control store may be written to, which allows
user written m i c r o c o d e to be executed.

The system is based
on
a
processor
described
by
Dasgupta
[7]
and
also by
T a n e n b a u m [I], which he calls a " h y p o t h e t ical
host
machine",
and
which
will be
referred to as the TIa processor
in
this
document.
This processor was used, rather
than inventing a new one, for a number
of
reasons.
The
most relevant r a t i o n a l e for
the choice was to ensure that
a commonly

sl

30
84

98
J

RAM

0

Figure

~

t

,"

i -- Th=' H y p o t h Q C i c a l

70

B

LJ

8

CPU

The GATE I n s t r u c t i o n s

m

IvlRIIIIIIIIIIIIT-V[7-11111111111111111111[I,]
~

~

8

1

~

~

~

2

1

tgtBtYtFtSt413t2tI

~

tO g B 7 8 5 4 3 2 I O

Eoch bit of o GATE instruction represents one oF the control points (See Fig.
A "t' bit ollows doto to move ocroes o control point, o "0' bit does not.
Bit 0 of eoch mtorolnetruotton Is the opcode - o GATE Inetruotton hoe
on opoode of "I'. Bite SB ond 3g control reodlng ond wrtttn 9 of morn
memory, reepecttvely.

The TEST I n s t r u c t i o n s

Unused

I

Mtorocoda Br~r~h
Addree9

I)

,

T
Test Register

ObJact bit

The TEST mtcrotnstruotion ollows ony bit of certoin registers to be tested.
In any named Field obovg, only one bit moy be non-zero or on error occurs.
The ootion of the TEST instruction is to exomlne the indicoted test register.
to s e e if the epeciFied bit (The TEST field obove. O-15) is equol to the
the volue of the Object Bit Field (I or 0). If so. o bronch is mode to the
microlnstruction specified by the Microcode Bronch Address Field. IF not,
t h e n the next instruction i n the normol sequence is executed. Opcode For
t h e TEST inetruotlon is 'O'.

The

Figure

2

--

Emulation

System

The

Microinstruotton

Formots

For example, the dual purpose command
'dump'
is
used
to
dump a set of m e m o r y
locations. Hence, the command
'udump'
is
used
to dump a set of control store locations.

The T1a emulator is a computer
program
which simulates the T1a hardware. It
'executes'
the
40-bit
microinstructlons
one
at a time, and permits editing, tracing, and dumping both
the
'macro'
store
and
the
control
store,
and
allows
the
examination
and modification
of all
internal machine registers.

The
dual
purpose
commands
consist
mainly
of data entry or tracing commands.
They include BREAK,
CLEAR,
DUMP,
ENTER,
LOAD,
STEP,
and
STORE.
Single purpose
commands are
CHANGE,
CONTINUE,
DISPLAY,
NOTRACE,
PROGRAM, QUIT, RESTORE, RUN, and
SAVE. However,
it
makes
more
sense
to
group
the
commands
functionally,
into
input~output
commands,
debugging~tracing
commands, and others.

The
entire
system
is
written
in
Berkeley
PASCAL[I],
and
runs
on
a VAX
11/780 under UNIX. The program itself uses
only
standard
language features, and can
be easily ported to other systems
running
PASCAL.
In
fact, the system is also running on an IBM PC, and the
effort
needed
to make the conversion was minimal.

Tracing

and

Debugging

These
commands
very
often
involve
creating, deleting, or using a breakpoint,
or an address (either m i c r o a d d r e s s or normal
address)
where
execution
will
be
suspended. When the p r o g r a m
counter
contains
the
address
of
a breakpoint, the
emulator stops running the current program
and returns to command level.
Breakpoints
are set in order to check the current contents of store, values in registers, or to
modify some
value.
The
ability
to
set
breakpoints
is
extremely
valuable while
d e b u g g i n g m i c r o c o d e (and m a c h i n e
code
as
well).

The emulator reads commands from
the
user's
terminal,
but allows the entry of
microcode
and
machine
code
from
userspecified
files.
All commands are single
word names, possibly followed
by
parameters
which can be either numeric or text.
As well, some commands apply to
microcode
only,
some to machine code only, and some
to both.
In cases
where
a command
may
apply
to both micro and machine code, the
micro command name will be the same as the
machine
code version, except it will have
the letter 'u' prepended to it.

71

The command break (or
ubreak)
takes
one
parameterthe address, either micro
or macro, at which the b r e a k p o i n t is to be
placed.
The
emulator then prints out the
address, and asks if
it
is
correct,
to
which
you
may
reply
'yes'
or
'no'.
Finally, the emulator asks if
this
is
a
tracepoint.
A tracepoint
is
a special
case of a breakpoint,
in
that
when
the
tracepoint
address is encounted, the emulator will begin to trace the e x e c u t i o n of
the
user programs by dumping i n s t r u c t i o n s
to the screen as they are
executed.
The
emulator
does not stop e x e c u t i n g when the
t r a c e p o i n t is seen, it simply
begins
the
trace.

SET (ie : I) are entered.
Entry ends with
a negative number. Now the emulator stores
the microword, and increments and displays
the next address value, and
asks
if
you
wish
to
continue.
This
process repeats
until all words are entered. It is assumed
that
words
to be entered are c o n s e c u t i v e
locations.

A micro
breakpoint
lasts
until
removed.
A macro
breakpoint
will
only
exist until it is e n c o u n t e r e d and causes a
break;
it
will
then
be
removed.
Tracepoints
will,
however,
exist
until
removed.

The c o r r e s p o n d i n g output
command
is
dump.
This
command allows main store or
m i c r o s t o r e to be d i s p l a y e d on the
screen.
Two
parameters,
the starting address and
the final address, must be s p e c i f i e d .
All
of
the m e m o r y l o c a t i o n s b e t w e e n these two
addresses (inclusive) will be
written
to
the terminal.

Breakpoints
are
removed
clear command.
One parameter,
of t-~e breakpoint,
must
be
breakpoint
(or
tracepoint)
removed.

For entering m a c h i n e code, the
first
address
is
entered
as
above,
but code
entry
is
input
as
either
hexadecimal,
octal,
or
decimal
numbers, d e p e n d i n g on
the input
mode
specified.
You
will
be
asked
for
the number base, which must be
one of 2, 8, 10, or 16.

using
the
the address
given.
The
is
then

It will not be often
that
microcode
will be d i r e c t l y entered into m e m o r y using
enter - it is too slow
and
clumsy.
More
often, we will want to read code from data
files. The load command
requires
a
file
name
argument,
and this file is expected
to contain the required m e m o r y
words.
In
the
case
of
microcode, this file may be
produced by the MPL compiler. In the
case
of
machine
code,
it may be entered by a
text editor, or by a user program.

After a b r e a k p o i n t has been seen during
emulation
of user code, the user may
enter commands. One useful one is the step
command, which causes the emulator to execute the next m a c h i n e (or micro)
instruction,
then
stop
again.
Single stepping
through code is very useful during
debugging.

Store permits saving the current contents o - - ~ i t h e r
m i c r o s t o r e or main memory.
It requires a file name argument, the name
of
the file which will contain the m e m o r y
contents. Later,
store
may
be
reloaded
from the same file using the load command.
Saving both main store and
microstore
in
this
way r e q u i r e s two separate files.
If
the
entire
processor
state,
including
tracepoints,
breakpoints,
all registers,
and all m e m o r y s needs to
be
saved,
then
this
can
be
done too.
The command save
keeps all of this i n f o r m a t i o n
on
a
called
'utool.SAVE'
in
the current UNIX
w o r k i n g directory. The m a c h i n e
state
may
be
recalled
using
the
restore command.
No'te that there is only o n ~
- many
states
may
be
kept only by r e n a m i n g old
v e r s i o n s of the file.
program :

Once a b r e a k p o i n t is encountered,
it
is
often
d e s i r e a b l e to resume p r o c e s s i n g
from
the
current
state,
the
continue
statement
is used for this purpose.
This
command may be entered after a b r e a k p o i n t
is
encountered
during program execution.
The result is
that
the
program
resumes
executing
where
it
left off. Changes in
the m a c h i n e r e g i s t e r s made with
a change
command will be in effect.
The e q u i v a l e n t
command for t r a c e p o i n t s is notrace.
After
a t r a c e p o i n t is seen, e n t e r i n g the notrace
command turns off tracing,
until
another
t r a c e p o i n t is encountered.

Input~Output Commands
I/O c o m m a n d s cause m e m o r y
or
registers
to
be
either
loaded or saved. For
example, a user may
directly
enter
into
m e m o r y from the terminal, either m i c r o c o d e
(in its b i n a r y form) or m a c h i n e
code
(in
various
forms)
by
use of the enter command.

The
command
program
is
a
unique
feature
of
the
microtool
system. It is
used by students to load
standard
microcode and m a c h i n e code s e q u e n c e s written by
the instructor. The command
will
request
one
integer
argument,
b e t w e e n 0 and 99.
The integer argument
represents
a code,
created
by
the
instructor,
to identify
assignments,
lab
exercises,
etc.
This
allows
students
to e x p e r i m e n t with standard code sequences before
writing
their
own
firmware.
The instructor is free to
change these code sequences at
will,
and

For entering microcode, the
user
is
first asked for the address. Then, the bit
p o s i t i o n s in the m i c r o w o r d which are to be

72

on
some
systems
(such
as UNIX) a usage
count for each student may be
maintained.
Numbers
entered
by students which do not
correspond to a real
code
file
cause
a
message to the student's terminal.

DEST
DEST

A gate consists of some number of transfer
statements,
one
c o m p u t a t i o n a l statement,
or both kinds mixed, with only one
computational statement per gate statement. The
gate statement is ended by two
semicolons
(;;),
so that one gate statement may span
many lines.

Quite often during the
debugging
of
microcode, a 'bad' value finds itself in a
register.
The ' c h a n g e '
command p e r m i t s
the
m o d i f i c a t i o n of processor r e g i s t e r s during
program
execution.
Two
arguments
are
expected:
the
first
is
the name of the
register to be changed, and the second
is
the
value
to
be stored in the register.
Legal register names
(Upper
case
only!)
are

D e s t i n a t i o n s and sources
are
specified as key words, r e p r e s e n t i n g T1a registers or operations. Registers, etc. may be
written
in
either
upper
or lower case.
Possible d e s t i n a t i o n s are:

:

A
MBR
PC

B
X
SP

C
MAR

: SOURCE;
or
= Simple_expression;

D
IR

A,B,C,D
The Change
reasonable

command is also
used
values at the outset.

The
display
command
is
display
all
of
the
machine
probably after a breakpoint.

to

A thru D are 16
bit registers.
The X register.
Memory Address
Register
Memory Data
Register.
Instruction
Register.
Program Counter.
Stack Pointer.
Main store.

iniX
MAR

used
to
registers,

MBR
IR

Other

PC
SP
memory

Commands

The quit command terminates the
emulation
system and causes a return to UNIX
command level.

The
T1a
processor
has
a
simple
arithmetic-logic
unit
(ALU),
which performs simple additions,
complements,
and
shifts.
As
well,
there
are
constants
stored in internal r e g i s t e r s wich
can
be
used
in computations. Constants available

Run will run the current m i c r o p r o g r a m
on the current contents of main memory. No
parameters are expected.

are:
1

-

The MPL Compiler
0
-I
sign

The
Microcode
Programming
Language
(MPL)
compiler
is provided for more convenient programming of the T1a
processor.
Rather
than dealing with individual bits,
fields, and opcodes, m n e m o n i c s are used to
specify
register
transfers,
microcode
addresses, and memory access.
The
syntax
is
much like that of an assembler in some
ways, and like a compiler in others.
The
compiler
described
here
was inspired by
[3], but includes many new features.

15

form

A

A simple
:

shift_op

16

bit

register,

= integer I.
- 16 bit integer zero.
- 16 bit two's c o m p l e m e n t
16 bit register, only
the sign bit is set.
- The integer constant 15.
expression

(sourcel

takes

the general

+ source2)

The operator 'shift op' may be
absent
or
may
be
one
of
eTther
'shift left'
or
'shift right'
In any case,
the- addition
indicated
would be performed, followed by
a shift of only one bit in
the
specified
direction.

There a r e two basic statement
types,
because
of
the
two
basic
instruction
types. GATE statements consist of
one
or
more
assignments, possibly including simple expressions. TEST statements
yield
a
test
m i c r o i n s t r u c t i o n , and include a test
bit and branch address.

The source operands above may
simply
be
constants, registers, or may be a complemented constant or register. The
one's
complement of register A is written

A gate statement may be
composed
of
many
individual
assignment
statements,
because s gate
instruction
may
perform
many
simultaneous
data
transfers.
The
general syntax of an assignment is

complement (A)
To shift the A register
would enter :

73

left one

bit,

we

A : shift left
/ Sets 4? 13,

(A + 0);;
33 /

where :
bit-number

The
procedure
for
accessing
main
memory
is fairly simple.
The address for
a m e m o r y read operation is
always
placed
in
the
MAR
prior
to the read o p e r a t i o n
being started. The result of the read is a
16 bit m e m o r y word, which is placed in the
MBR. Remember that reads
and
writes
are
performed
during subcycle 3 of the m i c r o sequence, and so the address can be
moved
to
the MAR during the same micro instruction.
A memory

read

could

MBR=
memory ( MAR
or 8S :
MBR:
memory;;

be written

as

register

MBR,
bit-constant

:

All of the following bit
expressions
test
bit
number
14
of
the i n s t r u c t i o n
register to see if it is set (=I) :
bit
bit
bit
bit
bit
bit

is
understood.
be the destina-

Any MPL s t a t e m e n t may be preeeeded by
one
or
more
labels,
which are symbolic
names r e p r e s e n t i n g the address
in m i c r o store of that statement.
For example, :
lab1:
tst1:

MBR:

memory;;

not
be
defined
but
all
labels
in the program.

Often a simple
unconditional
branch
instruction
would be useful.
There is no
such instruction in our processor, but the
MPL
compiler can c o n s t r u c t one.
The GOTO
statement
is
a variation
of
the
test
statement,
where
the intent is to b r a n c h
u n c o n d i t i o n a l l y to a d e s t i n a t i o n
address.
The c o n d i t i o n used is to test any bit, say
bit number 0, of the zero register,
which
has
all
bits
set to 0, against the constant bit 0. This always r e s u l t s in a true
condition,
and
therefore
will
always
result in a branch.
The
test
statement
would be :

before
must be

When

it is n e c e s s a r y to b r a n c h
to
a
microinstruction
out
of
the
normal sequence,
then
a test
statement
would
be
used.
There is always a condition involved, which is expressed
as
the
e q u a l i t y of a bit constant (I or 0) with a
specified bit in a particular register. If
the two are equal, then the b r a n c h will be
made; otherwise, the next
instruction
in
the control store will be executed.

particular

The general
if <bit
then

syntax

if bit (0, O) = 0
then goto <dest>;;
where <dest> is some
can be shortened to

is

expression>
goto < m i c r o a d d r e s s >

goto

form of a bit

label.

In

MPL,

this

<dest>;;

;;

The keywords 'then' and 'goto' are
always
optional, and either, both, or neither may
be present.
The general

(14, IR) = I
(14, IR)
14 of IR is I
14, IR is I
14 of IR
((14)of(IR)) is ((I))

There are o b v i o u s l y many forms possible
for
the
same
test statement. It is
assumed that individual
programmers
will
adopt a convention.

Here, 'lab1' and 'tst1' r e p r e s e n t the same
location in microstore. Later, these names
may be the object of a branch.
Labels need
they
are
used,
defined somewhere

X, IR, or 0.

is 0 or I. If omitted,
I is assumed.

In any place where
a comma
(,)
is
seen,
the
key word 'of' may be used. All
equal signs (=) may be replaced by the key
word 'is'. All p a r e n t h e s e s may be omitted,
and extra ones are ignored.

);;

since the use of the
MAR
MBR
must, however, always
tion of the read.

is a c o n s t a n t between
0 and 15.
is one of A,B,C,D,

An Example MPL Program:
A stack machine.

expression

is
bit
:

Here, a simple stack m a c h i n e is written
in
T1a m i c r o c o d e . There are only six
instructions, w h i c h are:

(register, bit-number)
bit-constant

74

Opcode

Instruction

000

PUSH the low 13 bits of the
instruction
POP
the top stack value into
the A register.
ADD
the top two stack values,
result on top.
SUBtract the second-from top
value from the top value,
result on top.
STOre the (Top-l) value into
the memory location given
by Top.
GET
the contents of the
address given by the top
of the stack, result goes
on Top.

001
100
101

110
111

Description

References

The opcodes
occupy
the
top
3
bits
of
the word. The code for this
instruction set could be written
in
many ways, and the sample solution is
not guarenteed to be optimal
in any
sense.
The solution is given in Figure
3 as an
MPL
compilation
listing.
Points to note are, first,
that
the
code
written
above
for
the FEC is
used
without
modification,
and
second,
that
the execute portion of
the fetch-execute
cycle
must
first
decode
the
instruction
opcode
to
determine which instruction
to execute.
this
decoding
.is performed
bit-by-bit, a limitation enforced
by
the
architecture
of
the
micro
machine.
A coding
sheet
has
been
devised
for use
as a guide for beginning students
coding in binary. It is also useful
as a
reminder
of the
fields,
transfers, and
formats found in the T1a
processor.
More
advanced
students
will
probably
write
their micro programs in MPL, or some other
higher
level
representation,
but
it is
probably
instructional
for
students
to
write
their
first
few m i c r o p r o g r a m s in
machine format.
Figure ~
shows
an
audited
session
with
microtool.
The session shows how to
load both control store and main
memory,
illustrates
the
dump
formats
for
both
memories, and shows how to dump the registers.
Note
that the example is still the
stack machine.
A breakpoint is set at the
last executable address in main store, and
the program is run- the result is that the
program
stops
after
executing
the last
instruction.
Since
there
is no
proper
'halt'
instruction, this is the suggested
method of halting a program.

75

[I]

Joy, W.N.,
"Berkeley
sion 2.0",

Graham, S.L., Haley, C.B.,
PASCAL
User's Manual VerOct. 1980.

[2]

Andrews, M., "Principles of
Firmware
Engineering in Microprogram Control",
Computer Science Press. 1980.

[3]

Tannenbaum,
A., "Structured Computer
Organization", Prentice-Hall, 1976.

[4]

Parker, J.R., "The Microtool
Processor
Emulation System", University of
Calgary
Computer
Science
research
report
number
82/110/29,
January
1983.

[5]

IEEE Education Committee (Model
Curriculum Subcommittee of the IEEE Computer Society), "A Curriculum in Computer Science and Engineering", preliminary version. Pub.
EH0119-8
Jan.
1977.

[6]

ACM Curriculum Committee on Computer
Science, " C u r r i c u l u m 68 - Recommendat i o n s f o r Academic Programs in
Computer
Science",
CACM Vol. 11 Number
3, March 1968.

[7]

Dasgupta, D.,
"The
Organization
of
Microprogram
Stores", Computing Surveys, Vol. 11 Number I, March, 1979.

[8]

ACM Curriculum Committee on
Computer
Science,
"Curriculum
Computer
Science", CACM, Vol. 22, No.
3, March,
1979.

(audit>

I::

Dump OP a l l

ut~ol

0.0
+:
Control
0 . 0 +:

Register

u l o a d mpl. o u t
etore
loaded,
udump 0 I 0

255

A

M i c ~ o c o d e Wo~d
I
l
I
....................................................
O>
I>
2>
3>
4>
5>
&>
7>
8>
9>
lO>

I::

O. 0 +: l o a d t e m p i
Main slope
loaded
0. 0 +: dump O t&
[
(
C
£
£
[
[
[
[
[
[
[
(
C
[
(
[

I::
G::
0::

t

O]
11
21
3]
4]
5]
63
71
8)
9]
I0]
11]
12]
131
14]
15]
16]

0 to

C
D
MBR
X
IR
Zero

0

0100000000000000000010000000000000000001
0000100000000000010000000100000000001001
0000000000101111000000000000000010000000
0000000000000010100000000000000010000000
0000000000100010010000000000000010000000
0000010000000000000000000100000000000101
1000000000000000000100000000000000000001
0000000000000000000000000000001100000000
0100010000000000000100000001000000000101
0000000000000000100000000000000000000001
0000000000000000000000000000001100000000
0
~wom

OATE i n s t r u c t i o n .
DATE i n s t r u c t i o n .
TEST i n s t r u c t i o n ~
TEST i n s t r u c t i o n ,
TEST i n s t P u c t i o n ,
GATE I n s t r u c t i o n .
GATE i n s t r u c t i o n .
TEST i n s t r u c t i o n ,
GATE i n s t r u c t i o n .
GATE i n s t r u c t i o n .
TEST I n s t r u c t i o n ,

GoTo
OoTo
GoTo

11
0
8

GoTo

PC
SP
MAR

goTo

0

15

[
C
[

O] :
1] :
23 :

4896.7 +:

0
17
0

10

10

I

1

TEST

17

di~ple~
o~ a l l

Tla Registers

Value

Octal
Decimal
Octal
...........................................................

17 geS
; no

Op no

:

A
B
C
D
MBR
X
IR
Zero
PC
SP
MAR

~eS

He~
Contents
4000080001
0800404009
O00BO00080
0002800080
0012400080
O000000000
0400004005
8000100001
0000000300
OOOO00OOO0
0000100001
4400101005
0000800001
0000000300
OOOOOOO000
O000000OO0
002E800080
0032400080
OO0000OO00
0000100001
440010100~
0000800001
4000900001
0000100001
9000108011
0000000300
OOO0000000
0000100001
4400101005
0000800001
4000900001
0210008011
9000004011
0000000300
O000OO0000
O05AqOOOSO
O00000000O
0000100001
4400101005
0000400001
O0005COOOl
4400501005
O000OO0000
8000200001
0000000300
0000000000
4000100001
0000400001
4000200001

Line
Numbe~

Statements

1:
~:
3:
4:
~:

fec:

ma~ = pcJ mb~ =
i r = mb~;
pc
i ~ b i t (15o i t )
iP b i t 114, i t )
iF b i t (13.
It)

memo~g(ma~)~*
pc + I ; ;
t h e n goto a r i t h o p s ; ;
t h e n goto Pec;~
t h e n g o t o pOpi~

7:
8:
9:

push:

sp = sp ÷ 1 ; ;
ma~ = s p ;
goto F e e ; ;

memorg

:

11:
12:
13:
14:
15:
lb:
17:
18:
19:
20:
21:
22:
23:
24:

pop:

0
17
17
16

I*
I*
/*

add:

50:
51:

iF
iF

= 1 then
= I then

goto
goto

bit
bit

(14,
(13,

iT)
it)

m a r = sp~
sp = $p ÷ ( - 1 ) ;
mbr
memo~q(mar);;
a = mbr;
mar = sp;
mb~ = memo~g(ma~);;
mar = sp;
mb~ = a + mbr;
memory(mar) = mbrJ;
goto Fee;;

sub:

0000000300

÷ (-1);

memops;;
sub;;

/*

Pop

into

mbr

/*

Top

into

mbr * /

*/

/*

Top = sum * /

mar : sp;
sp ~ sp + ( - 1 ) J
mb~
memorg(mar);;
/ ~ Pop i n t o
mb~ * /
a : mb~;
mar : sp;
mbr = memor~ImarlJ;
I * Top t o mbr * I
a = complement(a) + mb~;;
/* Subtract */
mb? = a + 1;
memorg(mar) = mbr;J / * r e s u l t t o t o p * /
9oto PecJ;

memops:

iF

sto:

met = sp;
sp = sp ÷ ( - 1 ) ;
mhr = memor~(ma~);;
/ * Pop * /
i ~ = mbr~
mar ~ sp~
sp = . s p + ( - 1 ) ;
mb~ = memorg ( m a ~ ) ; ;
/ * ZR = t o p , pop a g a i n t /
mar = i t ;
memoTg(ma~l = m b r ; ;
l e PerForm t h e s t o r e * /
g o t o Fee;;

get:

mar = sp;
i r = mb~i;
ma~ = i t ;

mbP = memorg(ma~);;
mhr = memorg(ma~};;

/*

Read t h e d a t a * /

ma~ = spJ
9 o t o FecJ~

memorg(mar)

/*

Onto top * /

3

- -

bit(13,

MPL

i~)

= 1 then goto g e t ; ;

Li~tin

9

76

= mb~J;

oF

O
0
0

GATE I n s t r u c t i o n .

Fetch n e x t t a r g e t i n s t r u c t i o n
Move i n s t e t o PC++ * I
Decode opcode * /

arithops:

26:
27:
29:
30:
31:
32:
33:
34:
35:
36:
37:
38:
39:
40:
41:
42:
43:
44:
45:
46:
47:
48:
49:

sp = sp

O
0
0

quit

mbr;;

ma~ = spJ
mb~ = memorMJJ
a = mb~;;
goto Fec;J

Contents
Decimal

6
0
0
0
0
0
O

10:

8000100001

Figur~

6
0
0
O
O
O
0
0
~1
21
20

Mic~oPC :
2
MicPoIR :
0000100000000000010000000100000000001001
+:

I n s t e u c t i o ~ , GoTo

12
3
32768

Dump

489&.7

30>
31>

0

0
21
0

Reglste~

0 . 0 +: c h a n g e SP 17
SP
is set to
17
8 , 0 +: b ~ e a k 17
Confirm 9 v e a k p o i n t a t a d d t e l s
Is this
a T~acePoint
( ~ e s o~ n o )
O, 0 +: d i s p l a g

(

0

O. 0 +: ~ u n
I : : Macro b P e a k p o l n t a t
4896.7 * : dump 0 2

l

O>
1>
2>
3>
4>
5>
5>
C 6>
•
7>
•
8>
•
8>
(
8>
<
9>
< 10>
( 11>
• II>
11>
• 12>
< 13>
• 13>
< 13>
• 14>
• 14>
15>
• 15>
( 16>
( 17>
< 17>
( 17>
( 18>
( 18>
( 19>
( 20>
• 21>
( 22>
< 22>
< 23>
( 23>
( 23>
( 24>
( 24>
< 24>
( 25>
( 25>
• 26>
< 27>
( 27>
< 28>
< 29>

0
0
0
0
O
0
0

Hic~oPC :
0
Mic~oIR :
0300000000000000000000000000000000000000

3

<
<
•
•
<
<

O
0
O
0
0
0
0

Contents
Decimal

0

32768
7
32768
5
40960
0
49152
0
5734~
0
57344
32768
0
49152
0

Micro
Address

Registers

Octal
Decimal
Octal
...........................................................

words.

Address

•
(
(
•
(
<
(
<
•
(
C

Tla

Value

/*

Get t o p

Stock

*/

Moohime

*I

O