docs/pdds/draft/pdd01_overview.pod

   1 # Copyright (C) 2001-2009, Parrot Foundation.
   2 # $Id$
   3
   4 =head1 [DRAFT] PDD 1: Overview
   5
   6 =head2 Abstract
   7
   8 A high-level overview of the Parrot virtual machine.
   9
  10 =head2 Version
  11
  12 $Revision$
  13
  14 =head2 Description
  15
  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
  24 coroutines.
  25
  26 =head2 Implementation
  27
  28 =head3 Parser
  29
  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.
  35
  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.
  45
  46 =head3 IMCC
  47
  48 The intermediate code compiler (IMCC) is the main F<parrot> executable,
  49 and encapsulates several core low-level components.
  50
  51 =head4 PASM & PIR parser
  52
  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).
  56
  57 =head4 Bytecode compiler
  58
  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.
  62
  63 Note that currently, the only way to generate bytecode is by first
  64 generating PASM or PIR.
  65
  66 =head4 Optimizer
  67
  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
  70 bytecode.
  71
  72 =head4 Interpreter
  73
  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.
  78
  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.
  84
  85 =head4 Standalone pieces
  86
  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
  90 separate executables.
  91
  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.
  96
  97 =head3 Subsystems
  98
  99 The following subsystems are each responsible for a key component of
 100 Parrot's core functionality.
 101
 102 =head4 I/O subsystem
 103
 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.
 108
 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
 111 program.
 112
 113 =head4 Regular expression engine
 114
 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.
 119
 120 The regular expression engine is available to any language running on
 121 Parrot.
 122
 123 =head4 Data transformation engine
 124
 125 The tree grammar engine (TGE) is also a general-purpose data
 126 transformation tool (somewhat similar to XSLT).
 127
 128 =head3 API Levels
 129
 130 =head4 Embedding
 131
 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.
 134
 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.
 140
 141 =head4 Extensions
 142
 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
 147 extension).
 148
 149 =head4 Guts
 150
 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
 154 internal routines).
 155
 156 =head3 Target Platforms
 157
 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.
 165
 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.
 171
 172
 173 =head2 Language Notes
 174
 175 =head3 Parrot for small platforms
 176
 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
 185 supported).
 186
 187 =head3 Bytecode compilation
 188
 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.
 192
 193 =head3 Your HLL in, Java, CLI, or whatever out
 194
 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.
 200
 201 =head2 References
 202
 203 To come.
 204
 205 =cut
 206
 207 __END__
 208 Local Variables:
 209   fill-column:78
 210 End: