|PCODE Interpereters 101 firstname.lastname@example.org (Carl Dawson) (1999-01-22)|
|Re: PCODE Interpereters 101 email@example.com (Dwight Hughes) (1999-01-23)|
|Re: PCODE Interpereters 101 firstname.lastname@example.org (1999-01-31)|
|Re: PCODE Interpereters 101 email@example.com (Tom Lane) (1999-02-03)|
|Re: PCODE Interpereters 101 firstname.lastname@example.org (1999-02-05)|
|Re: PCODE Interpereters 101 email@example.com (1999-02-05)|
|Re: PCODE Interpereters 101 firstname.lastname@example.org (Chris F Clark) (1999-02-10)|
|Re: PCODE Interpereters 101 email@example.com (Sam Roberts) (1999-02-12)|
|Re: PCODE Interpereters 101 firstname.lastname@example.org (Kevin B. Smith) (1999-02-15)|
|[5 later articles]|
|From:||email@example.com (Scott Amspoker)|
|Date:||31 Jan 1999 01:13:32 -0500|
"Carl Dawson" <firstname.lastname@example.org> wrote:
>I am after a background as to how PCODE interpreters function. Could
>someone help here or kindly point me in the direction of some
>(preferably web based) information.
I used to have the Pascal source for the P-code engine (how's that for
the chicken-and-the-egg problem). I'm not aware of any web-based info
but I still remember various implementation details of P-code.
Generally, P-code is very stack oriented similar to Java's bytecode.
That seems to be a popular model for interpreted virtual CPUs. One
interesting aspect of P-code is the manner in which it handled the
lexical nesting of procedures. Rather than use a "display" (an array
of frame pointers each corresponding to a lexical level), each stack
frame contained both a "static link" and a "dynamic link" to previous
stack frames. The dynamic link was identical to the typical C method
of pushing the old frame pointer when creating a new frame (i.e. it
pointed back to the previous stack frame). The static link pointed
back to the previous stack frame for the next outer procedure
lexically containing the current procedure. It could point back
several frames on the stack.
I always felt that P-code's static links weren't a very efficient way
to handle the problem. The PUSH and POP instructions (LOAD/SAVE,
whatever) contained the lexical level of the variable as well as its
offset within its stack frame. For "global" variables and variables
in the current frame, it was reasonably efficient. However, for
variables somewhere in between, the engine had to follow the static
links the necessary number of steps to locate the desired frame.
Scott Amspoker |
Return to the
Search the comp.compilers archives again.