[LMH] Ooh, look! List traffic!

[Mark J. Dulcey]

Jaap Weel wrote:

>  Even though on LISP machines the microcode has the added advantage that 
> it can be reprogrammed easily, the original reason for Microcode as 
> opposed to Hardwired Control is that you could conserve precious silicon 
> area by having a really simple control unit (in the CADR, practically 
> none, since the microcode instruction set is notoriously simple; I don't 
> know much about the Exploder, but I imagine it's similar). This is why 
> I'm not too worried about needing humongous amounts of silicon. Many 
> FPGA's have built-in fast RAM that could contain microcode.
> 
> Question: What is the Exploder microcode instruction set like? Is it 
> *much* different, conceptually, from CADR microcode? This would 
> determine the amount of FPGA area needed to implement the controller. If 
> it's anything like the CADR, my hunch is: not much.

I don't have any direct knowledge of the TI Explorer architecture, but I 
believe it's similar.

> Question: What is the word length on a uExploder again? (I'm sorry, I 
> can't ever keep the word lengths of all different LISP machines 
> detangled in my head.) The size of the datapath part of a design should 
> scale about linearly in the word length. Of course, it also depends on 
> how many different operations you need to do, how many registers you 
> need &c.

Like all machines in the LMI branch of LispM heritage, the Explorer and 
uExplorer had 32 bit words.

> Question: How much microcode is there? I.e. how much microcode RAM do 
> you need?

True, the CADR, and its direct descendent the LMI Lambda, had fairly 
simple microcontrollers. They made up for this by using a LOT of 
microcode. The CADR originally had 8K of 48-bit microwords; the machines 
were later expanded to 12K, and then to 16K, to accomodate the 
increasing complexity of the microcode over time. (Later software 
versions put more functions into microcode.)

The Lambda had 16K 64-bit microwords, and used most of it to implement 
the rather baroque macroinstruction set of the LispM. In addition, the 
Lambda had a 128K byte RAM - 64K 16 bit words - that was used for 
brute-force dispatching of the macroinstructions; by then, there were 
enough different formats that it took quite a few tests just to figure 
out what type of instruction something was, so the Lambda eliminated the 
problem with a complete jump table.

All of these processors have more microcode than you would find in a 
modern RISC processor, though perhaps not more than an x86 
implementation would have.

I don't know how much microcode the TI LispMs had.