Re: PCODE Interpereters 101 (Scott Amspoker)
31 Jan 1999 01:13:32 -0500

          From comp.compilers

Related articles
PCODE Interpereters 101 (Carl Dawson) (1999-01-22)
Re: PCODE Interpereters 101 (Dwight Hughes) (1999-01-23)
Re: PCODE Interpereters 101 (1999-01-31)
Re: PCODE Interpereters 101 (Tom Lane) (1999-02-03)
Re: PCODE Interpereters 101 (1999-02-05)
Re: PCODE Interpereters 101 (1999-02-05)
Re: PCODE Interpereters 101 (Chris F Clark) (1999-02-10)
Re: PCODE Interpereters 101 (Sam Roberts) (1999-02-12)
Re: PCODE Interpereters 101 (Kevin B. Smith) (1999-02-15)
[5 later articles]
| List of all articles for this month |

From: (Scott Amspoker)
Newsgroups: comp.compilers
Date: 31 Jan 1999 01:13:32 -0500
Organization: Compilers Central
References: 99-01-079
Keywords: Pascal, interpreter

"Carl Dawson" <> 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 | | |

Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.