Consider the
instruction set of the x86. The MOV instruction is actually
implemented as a small sequence of microinstructions. There is, in fact,
no dedicated series of gates and other electronic aparatus which
implements the operation of MOV. Instead, it is implemented as a
series (or sequence) of smaller operations, such as LOAD REGISTER,
ADD REGISTERS, etc. If you are not familiar with the processes of
microprogramming, then you should become so. Microprograms are
not stored in RAM. Instead, they are stored in ROM.
Microprograms can be stored in RAM. It may not be common to have a 'soft
microcodes' processor (one where the microcode is stored in volatile
memory and loaded when the machine boots), but they exist. I can see 3
from where I am sitting (2 PERQs and a Xerox Daybreak).
If you think of a normal machine code instruction, then there are several
steps that have to be performed to execute that instruction and fetch the
next one. You can represent that process either as a collection of random
logic, or as a state machine with one flip-flop per machine state (which
is how the Philips P850 does it), or as a program. The last is
essentially what microcode is.
For those who are aware of the operations of the
HP 21MX processors,
these are microprogrammed machines. As it happens, the user of
such a computer can alter the microprogramming. This is the computer
In other words the microcode is partially stored in RAM on this machine.
Now, it is true that the printed text of the
program must be converted to
the instruction set of the computer but, the process is like this.
"CAR" corresponds to the instruction with byte code 0x01
"CDR" corresponds to the instruction with byte code 0x02
and so on. Of course, the byte values I give are only examples. The
true translations are not known to me. However, each operator of
the Lisp language will correspond to a single instruction code of the
Lisp machine.
There is a problem here. The process of programming in Lisp is
essentially defining new functions. So either _all_ of these are stored
in microcode (which would require a very large control store) or more
likely (and I happen to know that the PERQ Spice LISP does it this way),
there are some 'core' functions (like CAR, CDR, CONS, etc) that are
implemented as microcode, and higher level functions, including ones
defined by the user are defined in terms of these (and other higher level
functions).
In which case, the program that translates a user definition into the
calls to both microcode and 'machine code' functions is pretty similar to
a normal Lisp implementation running on a micro (many of which do not
compile all user input to the machine code of the CPU they happen to run
on). It's dubious whether you call that an interpretter or a compiler,
though.
-tony
Of course, I over simplified the discussion but, only to get my point
across.
Sure, it is possible for the microcode to be in RAM. The IBM 370's were
just such machines. More than once, while I was an operator of such
computers, the service representative came to the site, opened a panel
on the operator console, and changed the 5 1/4" floppy disk. By doing
so, he changed the microprogram of the computer. This microprogram
was loaded each time the computer was powered on.
For the x86 however, the microcode is hardcoded into the chip.
My wish is for a computer system that provides for dynamically modifiable
microcode, so that my self-modifying programs could obtain a new level
of self-modifyability!
As for the Lisp difficulties, remember, it takes only a few of the basic
operators to define the language. All else can be derived from same,
and AFAIK is derived from same. So, there is no need to implement
derivable functions in microcode.
William R. Buckley