Loading AI tools
American computer scientist From Wikipedia, the free encyclopedia
Joel McCormack is an American computer scientist who designed the NCR Corporation version of the p-code machine, which is a kind of stack machine popular in the 1970s as the preferred way to implement new computing architectures and languages such as Pascal and BCPL. The NCR design shares no common architecture with the Pascal MicroEngine designed by Western Digital but both were meant to execute the UCSD p-System.[1,2]
Urs Ammann, a student of Niklaus Wirth, originally presented p-code in his PhD thesis (see Urs Ammann, On Code Generation in a Pascal Compiler, Software: Practice and Experience, Vol. 7, No. 3, 1977, pp. 391–423). The central idea is that a complex software system is coded for a non-existent, fictitious, minimal computer or virtual machine and that computer is realized on specific real hardware with an interpreting computer program that is typically small, simple, and quickly developed. The Pascal programming language had to be re-written for every new computer being acquired, so Ammann proposed writing the system one time to a virtual architecture. The successful academic implementation of Pascal was the UCSD p-System developed by Kenneth Bowles, a professor at UCSD, who began the project of developing a universal Pascal programming environment using the P-machine architecture for the multitude of different computing platforms in use at that time. McCormack was part of a team of undergraduates working on the project.[3] He took this familiarity and experience with him to NCR.
NCR hired McCormack directly out of college. They had previously developed a bit-sliced hardware implementation of a p-code machine using AMD's AM2900 chipset. A myriad of timing and performance problems plagued the machine; McCormack proposed a redesign of the processor, which would have a microsequencer based on programmable logic. When McCormack left NCR to start Volition Systems he continued his work on the processor as a contractor.
This new CPU used horizontal microcode which radically enhanced parallelism within the microarchitecture. These wide, 80-bit microwords allowed the CPU to perform many operations in a single microcycle: the processor could do an arithmetic operation while also performing a memory read into the internal stack, or transfer the contents of a register while at the same time reading new data into the ALU. Resultingly, many of the simpler p-code operations only took one or two microinstructions; some operations were constructed with tight, single-microword loops.
Two bits per clock selected one of four cycle times for each instruction: 130, 150, or 175 nanoseconds, which generated with a delay line. Faster parts from AMD would have also allowed for a 98 ns cycle time, but there was no correspondingly faster branch control unit. A separate prefetch/instruction formatting unit also used delay lines to generate asynchronous timing signals. This unit had a 32-bit buffer and could decode the next data in multiple formats: signed byte; unsigned byte; word; and compressed "big" format, which encoded small numbers in 0..127 in a single byte, and larger numbers within 128..32767 in two.
An on-board stack of 1024, 16-bit words held temporary values—scalars as well as sets. The stack addresses ran downwards, with the stack pointer decrementing before a write and incrementing after a read. A register in the AMD 2901's internal file held the top-of-stack value so as to accelerate simple operations. Integer addition took only a single instruction cycle; since one operand was always in the register file, only one fetch from stack memory was needed.
Each wide control word could either hold the address of the next microinstruction or it could control the next p-machine instruction to be fetched. Thus, the microsequencer could jump almost arbitrarily the control code. The first 256 microinstructions in memory corresponded to p-machine instructions, so the microassembler would place the first control word in its corresponding location. P-code instructions that took multiple multiple microinstructions to execute could not start with a branch, (as this field is already used to jump to the rest of the microprogram for the instruction). [citation needed]
The CPU used the technique of keeping the top word of the stack in one of the AMD 2901 registers. This often resulted in one fewer microinstructions. For example, here are a few p-codes the way they ended up. tos is a register, and q is a register. "|" means parallel activities in a single cycle. (The stack doesn't quite operate this way...it decrements before data is written to it, and increments after data is read.)
Since next-address control and next microcode location were in each wide microword, there was no penalty for any-order execution of the microcode. A table of 256 labels, and the microcode compiler moved the first instruction at each of those labels to the first 256 locations of microcode memory. The only restriction this placed upon the microcode was that if the p-code required more than one microinstruction, then the first microinstruction couldn't have any flow control specified (as it would be filled in with a "goto <rest of microcode for p-code>).
fetch % Fetch and save in an AMD register the next byte opcode from
% the prefetch unit, and go to that location in the microcode.
q := ubyte | goto ubyte
SLDCI % Short load constant integer (push opcode byte)
% Push top-of-stack AMD register onto real stack, load
% the top-of-stack register with the fetched opcode that got us here
dec(sp) | stack := tos | tos := q | goto fetch
LDCI % Load constant integer (push opcode word)
% A lot like SLDCI, except fetch 2-byte word and "push" on stack
dec(sp) | stack := tos | tos := word | goto fetch
SLDL1 % Short load local variable at offset 1
% mpd0 is a pointer to local data at offset 0. Write appropriate
% data address into the byte-addressed memory-address-register
mar := mpd0+2
% Push tos, load new tos from memory
SLDX dec(sp) | stack := tos | tos := memword | goto fetch
LDL % Load local variable at offset specified by "big" operand
r0 := big
mar := mpd0 + r0 | goto sldx
INCR % Increment top-of-stack by big operand
tos := tos + big | goto fetch
ADI % Add two words on top of stack
tos := tos + stack | inc(sp) | goto fetch
EQUI % Top two words of stack equal?
test tos - stack | inc(sp)
tos := 0 | if ~zero goto fetch
tos := 1 | goto fetch
This architecture should be compared to the original P-code machine specification as proposed by Niklaus Wirth.
The end result was a 9"x11" board for the CPU that ran UCSD p-System faster than anything else, by a wide margin. As much as 35-50 times faster than the LSI-11 interpreter, and 7-9 times faster than the Western Digital Pascal MicroEngine did by replacing the LSI-11 microcode with p-code microcode. It also ran faster than the Niklaus Wirth Lilith machine but lacked the bit-mapped graphics capabilities, and around the same speed as a VAX-11/750 running native code. (But the VAX was hampered by the poor code coming out of the Berkeley Pascal compiler, and was also a 32-bit machine.)
Seamless Wikipedia browsing. On steroids.
Every time you click a link to Wikipedia, Wiktionary or Wikiquote in your browser's search results, it will show the modern Wikiwand interface.
Wikiwand extension is a five stars, simple, with minimum permission required to keep your browsing private, safe and transparent.