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