docs/overview.pod

   1 # Copyright (C) 2001-2006, Parrot Foundation.
   2 # $Id$
   3
   4 =head1 NAME
   5
   6 docs/overview.pod - A Parrot Overview
   7
   8 =head1 The Parrot Interpreter
   9
  10 This document is an introduction to the structure of and the concepts used by
  11 the Parrot shared bytecode compiler/interpreter system. We will primarily
  12 concern ourselves with the interpreter, since this is the target platform for
  13 which all compiler frontends should compile their code.
  14
  15 =head1 The Software CPU
  16
  17 Like all interpreter systems of its kind, the Parrot interpreter is a virtual
  18 machine; this is another way of saying that it is a software CPU. However,
  19 unlike other VMs, the Parrot interpreter is designed to more closely mirror
  20 hardware CPUs.
  21
  22 For instance, the Parrot VM will have a register architecture, rather than a
  23 stack architecture. It will also have extremely low-level operations, more
  24 similar to Java's than the medium-level ops of Perl and Python and the like.
  25
  26 The reasoning for this decision is primarily that by resembling the underlying
  27 hardware to some extent, it's possible to compile down Parrot bytecode to
  28 efficient native machine language.
  29
  30 Moreover, many programs in high-level languages consist of nested function
  31 and method calls, sometimes with lexical variables to hold intermediate
  32 results.  Under non-JIT settings, a stack-based VM will be popping and then
  33 pushing the same operands many times, while a register-based VM will simply
  34 allocate the right amount of registers and operate on them, which can
  35 significantly reduce the amount of operations and CPU time.
  36
  37 To be more specific about the software CPU, it will contain a large number of
  38 registers. The current design provides for four groups of N registers; each
  39 group will hold a different data type: integers, floating-point numbers,
  40 strings, and PMCs. (Polymorphic Containers, detailed below.)
  41
  42 Registers will be stored in register frames, which can be pushed and popped
  43 onto the register stack. For instance, a subroutine or a block might need its
  44 own register frame.
  45
  46 =head1 The Operations
  47
  48 The Parrot interpreter has a large number of very low level instructions, and
  49 it is expected that high-level languages will compile down to a medium-level
  50 language before outputting pure Parrot machine code.
  51
  52 Operations will be represented by several bytes of Parrot machine code; the
  53 first C<INTVAL> will specify the operation number, and the remaining arguments
  54 will be operator-specific. Operations will usually be targeted at a specific
  55 data type and register type; so, for instance, the C<dec_i_c> takes two
  56 C<INTVAL>s as arguments, and decrements contents of the integer register
  57 designated by the first C<INTVAL> by the value in the second C<INTVAL>.
  58 Naturally, operations which act on C<FLOATVAL> registers will use C<FLOATVAL>s
  59 for constants; however, since the first argument is almost always a register
  60 B<number> rather than actual data, even operations on string and PMC registers
  61 will take an C<INTVAL> as the first argument.
  62
  63 As in Perl, Parrot ops will return the pointer to the next operation in the
  64 bytecode stream. Although ops will have a predetermined number and size of
  65 arguments, it's cheaper to have the individual ops skip over their arguments
  66 returning the next operation, rather than looking up in a table the number of
  67 bytes to skip over for a given opcode.
  68
  69 There will be global and private opcode tables; that is to say, an area of the
  70 bytecode can define a set of custom operations that it will use.  These areas
  71 will roughly map to the subroutines of the original source; each precompiled
  72 module will have its own opcode table.
  73
  74 For a closer look at Parrot ops, see F<docs/pdds/pdd06_pasm.pod>.
  75
  76 =head1 PMCs
  77
  78 PMCs are roughly equivalent to the C<SV>, C<AV> and C<HV> (and more complex
  79 types) defined in Perl 5, and almost exactly equivalent to C<PythonObject>
  80 types in Python. They are a completely abstracted data type; they may be
  81 string, integer, code or anything else. As we will see shortly, they can be
  82 expected to behave in certain ways when instructed to perform certain
  83 operations - such as incrementing by one, converting their value to an integer,
  84 and so on.
  85
  86 The fact of their abstraction allows us to treat PMCs as, roughly speaking, a
  87 standard API for dealing with data. If we're executing Perl code, we can
  88 manufacture PMCs that behave like Perl scalars, and the operations we perform
  89 on them will do Perlish things; if we execute Python code, we can manufacture
  90 PMCs with Python operations, and the same underlying bytecode will now perform
  91 Pythonic activities.
  92
  93 For documentation on the specific PMCs that ship with Parrot, see the
  94 F<docs/pmc> directory.
  95
  96 =head1 Vtables
  97
  98 The way we achieve this abstraction is to assign to each PMC a set of function
  99 pointers that determine how it ought to behave when asked to do various things.
 100 In a sense, you can regard a PMC as an object in an abstract virtual class; the
 101 PMC needs a set of methods to be defined in order to respond to method calls.
 102 These sets of methods are called B<vtables>.
 103
 104 A vtable is, more strictly speaking, a structure which expects to be filled
 105 with function pointers. The PMC contains a pointer to the vtable structure
 106 which implements its behavior. Hence, when we ask a PMC for its length, we're
 107 essentially calling the C<length> method on the PMC; this is implemented by
 108 looking up the C<length> slot in the vtable that the PMC points to, and calling
 109 the resulting function pointer with the PMC as argument: essentially,
 110
 111     (pmc->vtable->length)(pmc);
 112
 113 If our PMC is a string and has a vtable which implements Perl-like string
 114 operations, this will return the length of the string. If, on the other hand,
 115 the PMC is an array, we might get back the number of elements in the array. (If
 116 that's what we want it to do.)
 117
 118 Similarly, if we call the increment operator on a Perl string, we should get
 119 the next string in alphabetic sequence; if we call it on a Python value, we may
 120 well get an error to the effect that Python doesn't have an increment operator
 121 suggesting a bug in the compiler front-end. Or it might use a "super-compatible
 122 Python vtable" doing the right thing anyway to allow sharing data between
 123 Python programs and other languages more easily.
 124
 125 At any rate, the point is that vtables allow us to separate out the basic
 126 operations common to all programming languages - addition, length,
 127 concatenation, and so on - from the specific behavior demanded by individual
 128 languages. Perl 6 will be Perl by passing Parrot a set of Perlish vtables;
 129 Parrot will equally be able to run Python, Tcl, Ruby or whatever by linking in
 130 a set of vtables which implement the behaviors of values in those languages.
 131 Combining this with the custom opcode tables mentioned above, you should be
 132 able to see how Parrot is essentially a language independent base for building
 133 runtimes for bytecompiled languages.
 134
 135 One interesting thing about vtables is that you can construct them dynamically.
 136 You can find out more about vtables in F<docs/vtables.pod>.
 137
 138 =head1 String Handling
 139
 140 Parrot provides a programmer-friendly view of strings. The Parrot string
 141 handling subsection handles all the work of memory allocation, expansion, and
 142 so on behind the scenes. It also deals with some of the encoding headaches that
 143 can plague Unicode-aware languages.
 144
 145 This is done primarily by a similar vtable system to that used by PMCs; each
 146 encoding will specify functions such as the maximum number of bytes to allocate
 147 for a character, the length of a string in characters, the offset of a given
 148 character in a string, and so on. They will, of course, provide a transcoding
 149 function either to the other encodings or just to Unicode for use as a pivot.
 150
 151 The string handling API is explained in F<docs/strings.pod>.
 152
 153 =head1 Bytecode format
 154
 155 We have already explained the format of the main stream of bytecode; operations
 156 will be followed by arguments packed in such a format as the individual
 157 operations require. This makes up the third section of a Parrot bytecode file;
 158 frozen representations of Parrot programs have the following structure.
 159
 160 Firstly, a magic number is presented to identify the bytecode file as Parrot
 161 code. Next comes the fixup segment, which contains pointers to global variable
 162 storage and other memory locations required by the main opcode segment. On
 163 disk, the actual pointers will be zeroed out, and the bytecode loader will
 164 replace them by the memory addresses allocated by the running instance of the
 165 interpreter.
 166
 167 Similarly, the next segment defines all string and PMC constants used in the
 168 code. The loader will reconstruct these constants, fixing references to the
 169 constants in the opcode segment with the addresses of the newly reconstructed
 170 data.
 171
 172 As we know, the opcode segment is next. This is optionally followed by a code
 173 segment for debugging purposes, which contains a munged form of the original
 174 program file.
 175
 176 The bytecode format is fully documented in F<docs/parrotbyte.pod>.
 177