The term p-code was derived from the term "pseudocode" because p-code consists of a RISC-like set of instructions for a "make-believe" processor. At run time, this processor, usually known as a stack machine (because it uses a stack for practically all its operations), is simulated by the built-in interpreter. (Just so you know, a "normal" processor uses registers and a stack primarily to pass values to and from function calls.) Because of its imaginary nature, the processor's instruction set never needs to change; instead, each instruction is mapped, via a lookup table, to a real instruction on any given processor. Logically, then, all that's required to move code from one processor to another is this mapping-code generation remains largely unaffected.
In a nutshell, p-code is an intermediate step between the high-level instructions in your Visual Basic program and the low-level native code executed by your computer's processor. At run time, Visual Basic translates each p-code statement to native code.
With p-code, typical size reduction from native code is more than 50 percent. For example, when the VisData sample that is included on the Visual Basic 5 CD is compiled to p-code, the resulting executable is less than half the size it would be if compiled to native code (396 KB vs. 792 KB). Additionally, compiling p-code is a lot faster than compiling to native code-around seven times faster. (Some of the reasons for the speed of p-code compiling will become evident later in the chapter.) You'll need to keep this compile-time difference in mind during your development and testing phases. These compile timings, and all the other timings in this chapter, were made using prerelease builds of Visual Basic 6. If you're interested in these timings, you should conduct your own tests using the actual product.
Back in the days of Visual Basic 4 and earlier, a native code compiler was, I think, one of the most requested features, so I'm not surprised to find that Microsoft put it in Visual Basic 5-and, of course, the native code compiler is basically the same feature in Visual Basic 6. Personally, however, I think that native code compilation, for many reasons (and forgetting for a second that it typically executes faster) is a backward step. I'm still convinced that p-code is ultimately a superior technology compared to native code generation, as does, apparently, Sun Microsystems, because Java is essentially doing the same thing! Ever since the first version of Visual Basic, its p-code output has been, or could have been, roughly equivalent to Java's bytecodes. If a Visual Basic program had to be instantiated using the Visual Basic "virtual machine" (that is, something like vbrun100 <AppName>) and if that virtual machine were to be ported to different, non-Intel architectures, Visual Basic could have perhaps led the way to what's now become "bytecode nerdvana" instead of being criticized in its p-code form for being both slow and interpreted (just like pure Java is, in fact) Not convinced? Here's one of Sun's own descriptions of bytecode technology.
[On Java being a portable technology] "The Java compiler does this by generating bytecode instructions that have nothing to do with a particular computer architecture. Rather, they are designed to be both easy to interpret on any machine and easily translated into native machine code on the fly." I'm sure the similarity between the two is obvious.
If you want to read some more stuff about p-code that isn't specific to Visual Basic, search MSDN for "Microsoft P-Code Technology" and see Andy Padawer's excellent paper on the subject.
