Comment by kragen | Hacker News Reader

Comment by kragen | Hacker News Reader

Parent Full thread

the cpu tech ref you linked documents a machine with 512 20-bit registers (256 architectural—they duplicated the register file to avoid using dual- or triple-ported memory, same as the cadr). p-code doesn't have registers. the microcode word format it documents uses 48-bit instructions. p-code instructions are typically about 8 bits wide. the cpu tech ref also doesn't mention pascal or p-code

based on this it seems reasonable to continue believing that, as graydon says, it ran pascal via a p-code interpreter, but that that interpreter was implemented in microcode

and i don't think it's accurate to say 'the cpu board was all logic chips implementing the p-code machine language'. the logic chips implemented microcode execution; the microcode implemented p-code

i agree that this is the same extent to which lisp machines implemented lisp—but evidently the perq also ran cmucl, c, and fortran, so i don't think it's entirely accurate to describe it as 'a pascal machine'

> i don't think it's entirely accurate to describe it as 'a pascal machine'

yes

it would only be accurate, when one looks at BOTH the CPU and the microcode. The Xerox Interlisp-D machine was a Lisp Machine with the specific microcode. It was a Smalltalk machine and a Mesa machine - each with their microcode.

The original MIT Lisp machine was also microcoded, though I don't know other Microcode than the one for Lisp. The early Symbolics Lisp Machines were also microcoded, but again only for the Lisp OS, with the microcode evolving over time to support features of Common Lisp, Prolog and CLOS.

There were complaints that the Microcode on the Lisp Machines was very complex, which contributed to the death of the machines. For example here is an interview with Keith Diefendorff, who was also architect for the TI Explorer Lisp Machine. In his interview he talks about the Explorer Project and the Microcode topic: https://www.youtube.com/watch?v=9la7398ruXQ

The MIT Lisp Machine microcode feels like writing in a modern 3-address RISC instruction set to me. I see a lot of reluctance to modifying the source in old mailing lists, maybe everyone was told that it was too hard so didn't try.

EDIT: An example: The CADR has a nice API from Lisp to the CHAOSNET hardware, the microcode wakes up a stack group (thread) and passes it a buffer to process. Later machines had Ethernet but there isn't any microcode support for the hardware, Lisp code just polls the status of the ethernet controller and copies packets around a byte at a time. The microcode buffer handling routines for CHAOSNET could have been reused for Ethernet.

Issue with the CADR (and Lambda ..) microcode isn't that it is hard to modify, it is that there is a very deep snake pit, and lots of complex interaction between the microcode and the Lisp Machine.

The CADR already had support for (pre-)Ethernet via microcode very early (~1979) and did it more or less the same way as for Chaosnet. The Lambda I think modified this quite heavily though to something else ...

It's fair to say that x86 or x86-64 instructions are also emulated by some lower-level machine which maps the small number of registers onto a larger register file and translates instructions into something else.

Not in the same sense that the typical minicomputer CPU used microcode, no.

i agree, but i also think it's fair to say that the i386 and amd64 instruction sets are the native machine code they implement. both of these contradictory points of view are useful oversimplifications of reality that are useful for certain purposes

This is an interesting discussion, first it’s true that they implemented a p-code variant called q-code.

Second I’m just making a distinction about what people refer to as emulation. Although you could change the microcode, that typically meant you had to reprogram the board. Microcode is typically inaccessible outside of the cpu. Microcode provides sub-operations within the cpu.

just to be clear, the microcode instruction set is not a p-code variant, and in the case of the perq, the microcode memory was volatile memory that had to be loaded on every boot, and could easily be loaded with custom microcode. you didn't have to burn new eproms or anything

i don't think we have any substantive disagreements left, we're just getting tangled up in confusing, ambiguous terminology like 'native' and 'emulation'

Reply on news.ycombinator.com