|[TDR] Token-Based Compilers email@example.com (1993-01-20)|
|Re: [TDR] Token-Based Compilers firstname.lastname@example.org (1993-01-23)|
|P-Code (was Re: [TDR] Token-Based Compilers) email@example.com (1993-01-26)|
|From:||firstname.lastname@example.org (Mark Grand)|
|Date:||Tue, 26 Jan 1993 01:18:01 GMT|
email@example.com (Patrick C. Beard) said:
> I believe Microsoft uses P-Code in many of its shipping
> products for the Macintosh. ... I am very interested in finding out what
> the various trade-offs are in compiling to pseudo code. And what type of
> instructions to provide. I am thinking very seriously about
> writing a C interpreter using just such a technique. Has
> anybody any references on designs of P-Code instruction sets?
The P-Code that Microsoft uses is for the purpose of minimizing the isze
of the executable. The p-code that they use is substantially more compact
than native 8086 code.
Another circumstance in which p-code is a reasonable choice is when there
is an enormous semantic gap separating the source language from the native
instruction set. For example, there are a number of specialized languages
for building database related applications. Because of the large number
of operations they perform related to database manipulation, data
formatting and screen formatting, well over 90% of the time in these
programs is spent inside of the equivalent of a run time library. For
languages such as these, compiling to machine code does not usually
provide enough of an improvement to justify the effort of implementing a
machine code back end.
Yet another advantage of P-Code is that it can provide hardware
independence. P-Code can be designed so that it can be moved from one
type of computer hardware to another without need for access to source
Premenos Corporation 510-602-2000
1000 Burnett, Second Floor firstname.lastname@example.org
Concord, CA 94520
Return to the
Search the comp.compilers archives again.