P-code machine

While a typical compiler model is aimed at translating a program code into machine code, the idea of a P-code machine follows a two-stage approach involving translation into P-code and execution by interpreting or just-in-time compilation (JIT) through the P-code machine. This separation makes it possible to detach the development of a P-code interpreter from the underlying machine code compiler, which has to consider machine-dependent behaviour in generating its bytecode. This way a P-code interpreter can also be implemented quicker, and the ability to interpret the code at runtime allows for additional run-time checks which might not be similarly available in native code. Further, as P-code is based on an ideal virtual machine, a P-code program can often be smaller than the same program translated to machine code. Conversely, the two-step interpretation of a P-code-based program leads to a slower execution speed, though this can sometimes be addressed with just-in-time compilation, and its simpler structure is easier to reverse-engineer than native code. ==Implementations of P-code==

In the early 1980s, at least two operating systems achieved machine independence through extensive use of P-code . The Business Operating System (BOS) was a cross-platform operating system designed to run P-code programs exclusively. The UCSD p-System, developed at The University of California, San Diego, was a self-compiling and self-hosting operating system based on P-code optimized for generation by the Pascal language. In the 1990s, translation into p-code became a popular strategy for implementations of languages such as Python, Microsoft P-Code in Visual Basic and Java bytecode in Java. The language Go uses a generic, portable assembly as a form of p-code, implemented by Ken Thompson as an extension of the work on Plan 9 from Bell Labs. Unlike Common Language Runtime (CLR) bytecode or JVM bytecode, there is no stable specification and the Go build tools do not emit a bytecode format to be used at a later time. The Go assembler uses the generic assembly language as an intermediate representation and the Go executables are machine-specific statically linked binaries. ==UCSD P-Machine==

Architecture Like many other P-code machines, the UCSD P-Machine is a stack machine, which means that most instructions take their operands from a stack, and place results back on the stack. Thus, the add instruction replaces the two topmost elements of the stack with their sum. A few instructions take an immediate argument. Like Pascal, the P-code is strongly typed, supporting Boolean (b), character (c), integer (i), real (r), set (s), and pointer (a) data types natively. Some simple instructions: Insn. Stack Stack Description before after   adi i1 i2 i1+i2 add two integers adr r1 r2 r1+r2 add two reals inn i1 s1 b1 set membership; b1 = whether i1 is a member of s1 ldi i1 i1 i1 load integer constant mov a1 a2 a2 move not b1 b1 -b1 Boolean negation Environment Similar to a real target CPU, the P-System has only one stack shared by procedure stack frames (providing return address, etc.) and the arguments to local instructions. Three of the machine's registers point into the stack (which grows upwards): • SP points to the top of the stack (the stack pointer). • MP marks the beginning of the active stack frame (the mark pointer). • EP points to the highest stack location used in the current procedure (the extreme pointer). Also present is a constant area, and, below that, the heap growing down towards the stack. The NP (the new pointer) register points to the top (lowest used address) of the heap. When EP gets greater than NP, the machine's memory is exhausted. The fifth register, PC, points at the current instruction in the code area. Calling conventions Stack frames look like this: EP -> local stack SP -> ... locals ... parameters ... return address (previous PC) previous EP dynamic link (previous MP) static link (MP of surrounding procedure) MP -> function return value The procedure calling sequence works as follows: The call is introduced with mst n where n specifies the difference in nesting levels (remember that Pascal supports nested procedures). This instruction will mark the stack, i.e. reserve the first five cells of the above stack frame, and initialize previous EP, dynamic, and static link. The caller then computes and pushes any parameters for the procedure, and then issues cup n, p to call a user procedure (n being the number of parameters, p the procedure's address). This will save the PC in the return address cell, and set the procedure's address as the new PC. User procedures begin with the two instructions ent 1, i ent 2, j The first sets SP to MP + i, the second sets EP to SP + j. So i essentially specifies the space reserved for locals (plus the number of parameters plus 5), and j gives the number of entries needed locally for the stack. Memory exhaustion is checked at this point. Returning to the caller is accomplished via retC with C giving the return type (i, r, c, b, a as above, and p for no return value). The return value has to be stored in the appropriate cell previously. On all types except p, returning will leave this value on the stack. Instead of calling a user procedure (cup), standard procedure q can be called with csp q These standard procedures are Pascal procedures like readln() (csp rln), sin() (csp sin), etc. Peculiarly eof() is a p-Code instruction instead. ==Example machine==

Niklaus Wirth specified a simple p-code machine in the 1976 book Algorithms + Data Structures = Programs. The machine had 3 registers - a program counter p, a base register b and a top-of-stack register t. There were 8 instructions: • lit 0, a : load constant • opr 0, a : execute operation (13 operations: RETURN, 5 mathematical functions, and 7 comparison functions) • lod l, a : load variable , • sto l, a : store variable , • cal l, a : call procedure at level • int 0, a : increment t-register by • jmp 0, a : jump to • jpc 0, a : jump conditional to ==Microsoft P-code==

As the goal of the company was to release software for all the major platforms and architectures that existed then. Between 1980 and 1982, Microsoft developed an early C compiler that produced P-Code (the C language itself was not standardized and wouldn't be until later in the 80s). The P-Code allowed software to run on most platforms with minimal code change. UCSD Pascal was using a similar approach. This C to P-Code was a success but was very slow. In 1983, Microsoft released the Microsoft C Compiler, MSC, based on a license of the Lattice C compiler for versions 1.0 and 2.0; then, from version 3.0 onward, the MSC was a complete rewrite by Microsoft. P-code is a name later used by some of Microsoft's intermediate languages. They provided an alternate binary format to machine code. At various times, Microsoft has said P-code is an abbreviation for either packed code or pseudo code. Some Microsoft P-code flavor, quite different from the one used by the C compiler, was widely used with Visual Basic which had a runtime that included a VM or could be directly compiled to native code. Like other P-code implementations, Microsoft P-code enabled a more compact executable at the expense of slower execution. ==Other implementations==