1 # Copyright (C) 2001-2009, Parrot Foundation.
4 =head1 [DRAFT] PDD 1: Overview
8 A high-level overview of the Parrot virtual machine.
16 Parrot is a virtual machine for dynamic languages like Python, PHP, Ruby, and
17 Perl. A dynamic language is one that allows things like extension of the code
18 base, subroutine and class definition, and altering the type system at
19 runtime. Static languages like Java or C# restrict these features to compile
20 time. If this sounds like an edgy idea, keep in mind that Lisp, one of the
21 prime examples of a dynamic language, has been around since 1958. The basic
22 paradigm shift to dynamic languages leads the way to other more advanced
23 dynamic features like higher-order functions, closures, continuations, and
30 While individual high-level languages may implement their own parser,
31 most will use Parrot's parser grammar engine (PGE). The parser grammar
32 engine compiles a parsing definition (.pg) file into an executable
33 parser for the language. The resulting parser takes source code as input
34 and creates a raw parse tree.
36 Subsequent stages of compilation convert the raw parse tree into an
37 annotated syntax tree. The tree grammar engine (TGE) compiles a
38 transformation definition (.tg) file into an executable set of rules to
39 transform data structures. In most compilers, the syntax tree goes
40 through a series of transformations, starting with the raw parse tree,
41 through a syntax tree that is close to the semantics of the HLL, and
42 ending in a syntax tree that is close to the semantics of Parrot's
43 bytecode. Some compilers will also insert optimization stages into the
44 compilation process between the common transformation stages.
48 The intermediate code compiler (IMCC) is the main F<parrot> executable,
49 and encapsulates several core low-level components.
51 =head4 PASM & PIR parser
53 This Bison and Flex based parser/lexer handles Parrot's assembly
54 language, PASM, and the slightly higher-level language, PIR (Parrot
55 Intermediate Representation).
57 =head4 Bytecode compiler
59 The bytecode compiler module takes a syntax tree from the parser and emits an
60 unoptimized stream of bytecode. This code is suitable for passing straight to
61 the interpreter, though it is probably not going to be very fast.
63 Note that currently, the only way to generate bytecode is by first
64 generating PASM or PIR.
68 The optimizer module takes the bytecode stream from the compiler and
69 optionally the syntax tree the bytecode was generated from, and optimizes the
74 The interpreter module takes the bytecode stream from either the optimizer or
75 the bytecode compiler and executes it. There must always be at least one
76 interpreter module available for any program that can handle all of Perl,
77 since it's required for use statements and BEGIN blocks.
79 While there must be at least one interpreter, there may be multiple
80 interpreter modules linked into an executable. This would be the case, for
81 example, for programs that produced Java bytecode, where one of the
82 interpreter modules would take the bytecode stream and spit out Java bytecode
83 instead of interpreting it.
85 =head4 Standalone pieces
87 Each piece of IMCC can, with enough support hidden away (in the form of an
88 interpreter for the parsing module, for example), stand on its own. This means
89 it's feasible to make the parser, bytecode compiler, optimizer and interpreter
92 This allows us to develop pieces independently. It also means we can
93 have a standalone optimizer which can spend a lot of time groveling over
94 bytecode, far more than you might want to devote to optimizing
95 one-liners or code that'll run only once or twice.
99 The following subsystems are each responsible for a key component of
100 Parrot's core functionality.
104 The I/O subsystem provides source- and platform-independent synchronous
105 and asynchronous I/O to Parrot. How this maps to the OS's underlying I/O
106 code is not generally Parrot's concern, and a platform isn't obligated
107 to provide asynchronous I/O.
109 Additionally, the I/O subsystem allows a program to push filters onto an
110 input stream if necessary, to manipulate the data before it is presented to a
113 =head4 Regular expression engine
115 The parser grammar engine (PGE) is also Parrot's regular expression
116 engine. The job of the regular expression engine is to compile regular
117 expression syntax (both Perl 5 compatible syntax and Perl 6 syntax) into
118 classes, and apply the matching rules of the classes to strings.
120 The regular expression engine is available to any language running on
123 =head4 Data transformation engine
125 The tree grammar engine (TGE) is also a general-purpose data
126 transformation tool (somewhat similar to XSLT).
132 The embedding API is the set of calls exported to an embedding application.
133 This is a small, simple set of calls, requiring minimum effort to use.
135 The goal is to provide an interface that a competent programmer who is
136 uninterested in Parrot internals can use to provide access to a Parrot
137 interpreter within another application with very little programming or
138 intellectual effort. Generally it should take less than thirty minutes for a
139 simple interface, though more complete integration will take longer.
143 The extension API is the set of calls exported to Parrot extensions. They
144 provide access to most of the things an extension needs to do, while hiding
145 the implementation details. (So that, for example, we can change the way
146 scalars are stored without having to rewrite, or even recompile, an
151 The guts-level APIs are the routines used within a component. These aren't
152 guaranteed to be stable, and shouldn't be used outside a component. (For
153 example, an extension to the interpreter shouldn't call any of the parser's
156 =head3 Target Platforms
158 The ultimate goal of Parrot is portability to more-or-less the same
159 platforms as Perl 5, including AIX, BeOS, BSD/OS, Cygwin, Darwin,
160 Debian, DG/UX, DragonFlyBSD, Embedix, EPOC, FreeBSD, Gentoo, HP-UX,
161 IRIX, Linux, Mac OS (Classic), Mac OS X, Mandriva, Minix, MS-DOS,
162 NetBSD, NetWare, NonStop-UX, OpenBSD, OS/2, Plan 9, Red Hat, RISC OS,
163 Slackware, Solaris, SuSE, Syllable, Symbian, TiVo (Linux), Tru64,
164 Ubuntu, VMS, VOS, WinCE, Windows 95/98/Me/NT/2000/XP/Vista, and z/OS.
166 Recognizing the fact that ports depend on volunteer labor, the minimum
167 requirements for the 1.0 launch of Parrot are portability to major
168 versions of Linux, BSD, Mac OS X, and Windows released within 2 years
169 prior to the 1.0 release. As we approach the 1.0 release we will
170 actively seek porters for as many other platforms as possible.
173 =head2 Language Notes
175 =head3 Parrot for small platforms
177 One goal of the Parrot project, though not a requirement of the 1.0
178 release, is to run on small devices such as the Palm. For small
179 platforms, any parser, compiler, and optimizer modules are replaced with
180 a small bytecode loader module which reads in Parrot bytecode and passes
181 it to the interpreter for execution. Note that the lack of a parser will
182 limit the available functionality in some languages: for instance, in
183 Perl, string eval, do, use, and require will not be available (although
184 loading of precompiled modules via do, use, or require may be
187 =head3 Bytecode compilation
189 One straightforward use of the Parrot system is to precompile a program into
190 bytecode and save it for later use. Essentially, we would compile a program as
191 normal, but then simply freeze the bytecode to disk for later loading.
193 =head3 Your HLL in, Java, CLI, or whatever out
195 The previous section assumes that we will be emitting Parrot bytecode.
196 However, there are other possibilities: we could translate the bytecode
197 to Java bytecode or .NET code, or even to a native executable. In
198 principle, Parrot could also act as a front end to other modular
199 compilers such as gcc or HP's GEM compiler system.