4 ms·

A nit with TFA: the cpu board didn’t “emulate” P-Code, that was the native machine language. It was a “PASCAL machine” like the way we think of the Lisp Machine

by Isamu 2y ago

A nit with TFA: the cpu board didn’t “emulate” P-Code, that was the native machine language. It was a “PASCAL machine” like the way we think of the Lisp Machine. So the cpu board was all logic chips implementing the P-Code machine language, it wasn’t a cpu chip with supporting logic. That gives you an idea of computing in the old days. Back in the day PASCAL was the main teaching language at CMU. (Edit) There seems to be some pushback on what I’m pointing out here, but it’s true, the cpu board is not built around a cpu chip, they built a microcode sequencer, ALU, etc to execute a p-code variant. You can read about it here: http://bitsavers.org/pdf/perq/PERQ_CPU_Tech_Ref.pdf http://bitsavers.org/pdf/perq/PERQ_CPU_Tech_Ref.pdf Schematics here: http://bitsavers.org/pdf/perq/perq1/PERQ1A_Schematics/03_CPU-D.pdf http://bitsavers.org/pdf/perq/perq1/PERQ1A_Schematics/03_CPU... Pic: http://bitsavers.org/pdf/perq/perq1/PERQ1A_PCB_Pics/CPU_top.jpg http://bitsavers.org/pdf/perq/perq1/PERQ1A_PCB_Pics/CPU_top....

kragen 2y ago
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'
- Isamu 2y ago
  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.
  - kragen 2y ago
    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'
- kazinator 2y ago
  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.
  - formerly_proven 2y ago
    Not in the same sense that the typical minicomputer CPU used microcode, no.
  - kragen 2y ago
    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
- lispm 2y ago
  > 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 https://www.youtube.com/watch?v=9la7398ruXQ
  - rjsw 2y ago
    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.
    - amszmidt 2y ago
      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 ...
yencabulator 2y ago
What you linked to doesn't seem to conflict with the article at all. Article: > [...] user-written microcode and custom instruction sets, and the PERQ ran Pascal P-code. Through a microcode emulator. Things were wild. PDF: > It will also prove useful to advanced programmers who wish to modify the PERQ’s internal microcode and therefore need to understand how this microcode controls the operation of the CPU, [...] It sounds like it came with microcode that interpreted P-code, but that was user-changeable. The "wild" part is doing p-code interpretation in microcode, instead of a normal program. See also https://en.wikipedia.org/wiki/Pascal_MicroEngine https://en.wikipedia.org/wiki/Pascal_MicroEngine
- Isamu 2y ago
  I think we have a mild disagreement over what is meant by “emulation”. Typically this means the native instruction set is something other than what is being emulated. There is microcode inside cpu chips today too, they are used to implement parts of the instruction set. The microcode is not typically accessible outside of the cpu, and it is not considered the native machine language, the instruction set. The article you link to uses the word “emulator” once, to describe emulation on top of another system without this native support.
  - kragen 2y ago
    the 'microcode' inside cpu chips today is a totally different animal—it doesn't interpret the amd64 or other instruction set, but rather compiles (some of) it into the micro-operations supported natively by the hardware. but from the user's point of view the bigger difference is that the perq's microcode was accessible in the sense that you could write your own microcode and load it into the cpu. current popular cpus do have the ability to load new microcode, but that ability is heavily locked down, so you cannot control the microcode you are running microcode became a popular implementation technique in the 01960s and fell out of favor with the meteoric rise of risc in the 80s i think it's reasonable to say that an instruction set emulated by the microcode is a 'native instruction set' or 'native machine language'; it's as native as 8086 code was on the 8086 or lisp primitives were on the cadr. but in this case there were evidently several machine languages implemented in microcode, p-code being only one of them. so it's incorrect to say that p-code was the native machine language, it's incorrect to say that 'the cpu board was all logic chips implementing the p-code machine language', it's incorrect to say that 'they built a microcode sequencer (...) to execute a p-code variant', and it's incorrect to say 'they designed a board to execute p-code directly'

by Isamu 2y ago

kragen 2y ago

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'

Isamu 2y ago
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.
- kragen 2y ago
  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'
kazinator 2y ago
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.
- formerly_proven 2y ago
  Not in the same sense that the typical minicomputer CPU used microcode, no.
- kragen 2y ago
  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
lispm 2y ago
> 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 https://www.youtube.com/watch?v=9la7398ruXQ
- rjsw 2y ago
  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.
  - amszmidt 2y ago
    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 ...

yencabulator 2y ago

What you linked to doesn't seem to conflict with the article at all. Article: > [...] user-written microcode and custom instruction sets, and the PERQ ran Pascal P-code. Through a microcode emulator. Things were wild. PDF: > It will also prove useful to advanced programmers who wish to modify the PERQ’s internal microcode and therefore need to understand how this microcode controls the operation of the CPU, [...] It sounds like it came with microcode that interpreted P-code, but that was user-changeable. The "wild" part is doing p-code interpretation in microcode, instead of a normal program. See also https://en.wikipedia.org/wiki/Pascal_MicroEngine https://en.wikipedia.org/wiki/Pascal_MicroEngine

Isamu 2y ago
I think we have a mild disagreement over what is meant by “emulation”. Typically this means the native instruction set is something other than what is being emulated. There is microcode inside cpu chips today too, they are used to implement parts of the instruction set. The microcode is not typically accessible outside of the cpu, and it is not considered the native machine language, the instruction set. The article you link to uses the word “emulator” once, to describe emulation on top of another system without this native support.
- kragen 2y ago
  the 'microcode' inside cpu chips today is a totally different animal—it doesn't interpret the amd64 or other instruction set, but rather compiles (some of) it into the micro-operations supported natively by the hardware. but from the user's point of view the bigger difference is that the perq's microcode was accessible in the sense that you could write your own microcode and load it into the cpu. current popular cpus do have the ability to load new microcode, but that ability is heavily locked down, so you cannot control the microcode you are running microcode became a popular implementation technique in the 01960s and fell out of favor with the meteoric rise of risc in the 80s i think it's reasonable to say that an instruction set emulated by the microcode is a 'native instruction set' or 'native machine language'; it's as native as 8086 code was on the 8086 or lisp primitives were on the cadr. but in this case there were evidently several machine languages implemented in microcode, p-code being only one of them. so it's incorrect to say that p-code was the native machine language, it's incorrect to say that 'the cpu board was all logic chips implementing the p-code machine language', it's incorrect to say that 'they built a microcode sequencer (...) to execute a p-code variant', and it's incorrect to say 'they designed a board to execute p-code directly'