An approach to firmware engineering*
by
DAVID A. PATTERSON
University
of
California
Berkeley, California
INTRODUCTION
Although microprogramming has only been a research topic
for the past
10
years, the concept is nearly as old as com-
puters.
1
Wilkes originally defined microprogramming as a
systematic and orderly approach to the design
of
the control
section
of
a computer. Rather than using an
ad
hoc approach
with counters and decoders to generate control signals,
Wilkes proposed that the control be organized as a matrix.
This memory like approach to control remained largely
of
academic interest until the late 1950s. The first large-scale
microprogrammed computer was the IBM
7950
in
1961.
However, it was the introduction
of
the IBM SystemJ360
line (with
all but the largest system microprogrammed) that
revived interest in microprogramming. The advance in speed
and the reduction in cost
of
read-only memory (ROM) tech-
nology transformed microprogramming from an academic
concept
of
mild theoretical interest to a practical approach
to the design
of
commercial computers. 2 IBM was able to
offer several internally different models with the same in-
struction set in order to provide a spectrum
of
cost and
speed through the use
of
microprogramming. With the suc-
cess
of
the 360, several microprogrammed computers were
and are being built. In the late 60' s some manufacturers
made microprogramming available to the users. Nearly all
computer manufacturers have at least one computer imple-
mented via microprogramming, and the expanding list
of
manufacturers that provide user microprogrammable com-
puters include Burroughs (E 1700), Control Data Corporaton
(Cyber-17), Data General (Eclipse), Digital Equipment Cor-
poration
(PDP-11160)
and Hewlett Packard (HP-21MX). This
has expanded the potential domain
of
microprogrammers
from computer architects to systems and applications pro-
grammers.
While microprogramming and "ordinary" programming
have existed for almost the same amount
of
time, little
of
the considerable research in programming languages and
methodologies has impacted the microprogramming field.
Unfortunately, the following statement is a fairly accurate
description
of
the state
of
the microprogramming: 3
"At
present, microprogramming is an elite activity, per-
* This research was supported in
part
by the Department
of
Energy under
Contract EY-76-S-03-0034, PA214.
643
formed effectively only by a small number
of
expert prac-
titioners. The work is detailed, precise, time consuming,
and considerably more expensive than present-day soft-
ware programming. But, computer manufacturers have
found they can get dramatic improvements in system per-
formance by converting software into microprogrammed
form."
An approach to expanding the group
of
practitioners
of
microprogramming is to reduce the complexity and expense
of
firmware by providing tools similar to those that have
reduced the cost of software. The Strum system was de-
signed as a prototype to explore the benefits and detriments
of
such an approach.
SOFTWARE ENGINEERING TECHNIQUES
The most obvious technique to enhance the production
of
microprograms
is
to provide a high level microprogramming
language (HLML). One reason
HLMLs
have not been used
is
the importance of efficient firmware. With restricted size
and execution times being primary characteristics
of
micro-
programming, some doubt whether a
HLML
could ever
be
useful.
15
With the newer computers control memory has ex-
panded (e.g.,
16K
control memory
of
the HP-21mx) thereby
relieving some of the concern about size. A more important
aspect is the influx
of
applications microprogrammers who
have a very different set
of
constraints from the micropro-
grammer
of
the native instruction set. In the latter case one
may be able to justify doubling the effort to reduce execution
time by
10
percent. In the former case it is likely that ease
of
use, development cost and maintainability are much more
important than small gains in execution speed. The necessity
of
a high level microprogramming language is further illus-
trated by the Figure
1.
It
is widely accepted that the pro-
grammer spends half his time testing the program. This
figure indicates that a microprogrammer may spend half his
time coding the microprogram. As it is widely accepted that
a high level language will reduce coding time it makes emi-
nent sense to provide a high level microprogramming lan-
guage
if
it can produce reasonably efficient code.
Another technique that has reduced the time to develop
software is structured programming. This phrase is so widely
used that the criteria that determines whether a program is