Lisp, the machine language. Was Re: Hallelujah!

From: Buck Savage <hhacker_at_home.com>
Date: Sun Apr 4 16:55:14 1999

>> 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
Received on Sun Apr 04 1999 - 16:55:14 BST