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.
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.
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'
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.
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.
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'
They did design the CPU board absolutely with the intention of the "user facing" instruction set being a bytecode, though. In particular there's hardware support for an opcode file of up to the next 8 bytes in the instruction stream, which gets auto filled with a 64 bit memory load when it's empty. And there's a "256 way branch on the next byte in the opcode file" microcode instruction. The core of the thing is some standard AMD bitslice ALUs, but the board as a whole is clearly designed to let you implement a fast p-code interpreter.
The other thing the CPU board is designed for is fast graphics -- the rasterop hardware is set up so that with the right carefully designed microcode sequences it can do a 'load two sources, do a logical op and write to destination' as fast as the memory subsystem will let you do the 64 bit memory operations. It takes about four CPU cycles to do a memory operation, so you kick it off, do other microcode ops in the meantime, and then you can read the result in the microinsn that executes in 4 cycles' time. The rasterops microcode source code is all carefully annotated with comments about which T state each isnn executes in, so it stays in sync with the memory cycles.
The other fun thing is that the microcode sequencer gives you a branch "for free" in most insns -- there's a "next microinsn" field that is only sometimes used for other purposes. So the microcode assembler will happily scatter flow of execution all over the 4K of microcode ram as it places fragments to ensure that the parts that do need to go in sequence are in sequence and the parts at fixed addresses are at their fixed locations, and them fills in the rest wherever...
i see, thanks! i hadn't investigated it that deeply, and that definitely does sound optimized for implementing things like p-code interpreters (or 8080 emulators)
next-microinstruction fields are pretty common even in vertical microcode like this. do you have the microcode assembler running? have you written custom perq microcode?
I haven't turned my Perq 1 on in 20 years or so -- who knows if it would still run. I did play around with "what would microcode for a rot13 instruction look like" back when I was a student, but I didn't even try assembling it, let alone running it.
Except that the literature from Three Rivers Computing describes the “native instruction set is the P-code byte sequences that a compiler generates for an “ideal” PASCAL (or other structured language) machine.”
So I think we are quibbling, but it’s their words.
the literature you linked in https://news.ycombinator.com/item?id=41473755 (the cpu technical reference, bill of materials, and photo) doesn't say that, nor does it mention pascal or p-code. and the microcode instruction set documented in the cpu technical reference doesn't look anything like p-code. perhaps you're referring to some advertising materials?
i think we agree that it supports p-code as a native instruction set, but it's easy to draw incorrect inferences from that statement, such as your claim that the microcode sequencer executed a p-code variant. it would be reasonable inference from the literature you quote, but it's wrong
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
Schematics here: http://bitsavers.org/pdf/perq/perq1/PERQ1A_Schematics/03_CPU...
Pic: http://bitsavers.org/pdf/perq/perq1/PERQ1A_PCB_Pics/CPU_top....