1 # Copyright (C) 2001-2008, The Perl Foundation.
6 docs/glossary.pod - Parrot Glossary
10 Short descriptions of words and acronyms found in Parrot development.
15 Please keep this file alphabetical.
21 Abstract Syntax Tree: a data structure typically generated by a language
26 Byte Code Generation: bcg will be part of the Parrot Compiler
27 tools. It will aid in coverting POST to byte code.
31 Think of continuations as an execution "context". This context includes
32 everything local to that execution path, not just the stack. It is a snapshot
33 in time (minus global variables). While it is similar to C's C<setjmp> (taking
34 the continuation)/C<longjmp> (invoking the continuation), C<longjmp>'ing only
35 works "down" the stack; jumping "up" the stack (ie, back to a frame that has
36 returned) is bad. Continuations can work either way.
38 We can do two important things with continuations:
44 Create and pass a continuation object to a subroutine, which may recursively
45 pass that object up the call chain until, at some point, the continuation can
46 be called/executed to handle the final computation or return value. This is
47 pretty much tail recursion.
51 Continuations can be taken at an arbitrary call depth, freezing the call chain
52 (context) at that point in time. If we save that continuation object into a
53 variable, we can later reinstate the complete context by its "handle". This
54 allows neat things like backtracking that aren't easily done in conventional
55 stacked languages, such as C. Since continuations represent "branches" in
56 context, it requires an environment that uses some combination of heap-based
57 stacks, stack trees and/or stack copying.
61 It is common in a system that supports continuations to implement
62 L<co-routines|"Co-Routines"> on top of them.
64 A continuation is a sort of super-closure. When you take a continuation, it
65 makes a note of the current call stack and lexical scratchpads, along with the
66 current location in the code. When you invoke a continuation, the system drops
67 what it's doing, puts the call stack and scratchpads back, and jumps to the
68 execution point you were at when the continuation was taken. It is, in effect,
69 like you never left that point in your code.
71 Note that, like with closures, it only puts the B<scratchpads> back in scope -
72 it doesn't do anything with the values in the variables that are in those
77 Co-routines are virtually identical to normal subroutines, except while
78 subroutines always execute from their starting instruction to where they
79 return, co-routines may suspend themselves (or be suspended asynchronously if
80 the language permits) and resume at that point later. We can implement things
81 like "factories" with co-routines. If the co-routine never returns, every time
82 we call it, we "resume" the routine.
84 A co-routine is a subroutine that can stop in the middle, and start back up
85 later at the point you stopped. For example:
87 sub sample : coroutine {
104 Basically, the C<yield> keyword says, "Stop here, but the next time we're
105 called, pick up at the next statement." If you return from a co-routine, the
106 next invocation starts back at the beginning. Co-routines remember all their
107 state, local variables, and suchlike things.
111 Copy On Write: a technique that copies strings lazily.
113 If you have a string A, and make a copy of it to get string B, the two strings
114 should be identical, at least to start. With COW, they are, because string A
115 and string B aren't actually two separate strings - they're the same string,
116 marked COW. If either string A or string B are changed, the system notes it and
117 only at that point does it make a copy of the string data and change it.
119 If the program never actually changes the string - something that's fairly
120 common - the program need never make a copy, saving both memory and time.
124 Destruction is low level memory clean up, such as calling C<free> on
125 C<malloc>ed memory. This happens after L<"finalization">, and if resources are
126 adequate, may only happen as a side effect of program exit.
130 Dead Object Detection: the process of sweeping through all the objects,
131 variables, and whatnot inside of Parrot, and deciding which ones are in use and
132 which ones aren't. The ones that aren't in use are then freed up for later
133 reuse. (After they're destroyed, if active destruction is warranted.)
139 Finalization is high-level, user visible cleanup of objects, such as closing an
140 associated DB handle. Finalization reduces active objects down to passive
141 blocks of memory, but does not actually reclaim that memory. Memory is
142 reclaimed by the related L<"destruction"> operation, as and when necessary.
146 Garbage Collection: the process of sweeping through all the active objects,
147 variables, and structures, marking the memory they're using as in use, and all
148 other memory is freed up for later reuse.
150 Garbage Collection and Dead Object Detection are separate in Parrot, since we
151 generally chew through memory segments faster than we chew through objects.
152 (This is a characteristic peculiar to Perl and other languages that do string
153 processing. Other languages chew through objects faster than memory)
159 High-Level Language; Any of the languages that target the parrot virtual
164 International Components for Unicode
166 ICU is a C and C++ library that provides support for Unicode on a variety of
167 platforms. It was distributed with parrot at one time, but current releases
168 require you to get your own copy.
170 L<http://oss.software.ibm.com/icu/index.html>
174 Intermediate Code Compiler: the component of parrot that compiles PASM
175 and PIR into bytecode.
181 Just another Parrot Hacker: or, a small script that generates that text.
185 Method resolution order
189 Native Call Interface: parrot's interface to native "C" libraries,
190 without a C-compiler.
194 Not Quite Perl (6): designed to be a very small compiler for
195 quickly generating PIR routines to create transformers for Parrot (especially
202 Another name for a PBC file, due to the names used for data structures in one
203 of the early implementations in Perl 5.
207 Acronym for Parrot Abstract Syntax Tree, a set of classes that represent an
208 abstract syntax tree.
214 Parrot Byte Code. The name for the "executable" files that can be passed to the
215 Parrot interpreter for immediate execution (although PASM and IMC files can be
216 executed directly, too).
218 See also L<"Packfile">.
222 Parrot Compiler Toolkit: a complete set of tools and libraries
223 that are designed to create compilers targeting Parrot. The principal
224 components of PCT are PGE, PCT::HLLCompiler (a compiler driver), PAST classes,
225 POST classes, PCT::Grammar (a base class for PGE grammars).
227 In the ideal case, a language can be implemented by providing its parser
228 (using Perl 6 rules) which is generated by PGE, and providing a module written
229 in NQP that contains the I<actions> that are to be invoked during the parse.
230 These actions can then create the appropriate PAST nodes. A PAST to PIR
231 transformation already exists. Depending on the language, other phases can
232 be added, or overridden (for instance, the PAST to PIR transformation).
236 Acronym for PIR Compiler, a PIR compiler currently still in experimental
237 phase. The purpose is to reimplement the PIR language, which is currently
238 implemented by IMCC. There are two versions of PIRC: a handwritten, recursive-
239 descent top-down compiler, written in C, and a version using a Bison and
240 Flex grammar specification.
242 Some day, either PIRC should be completed, or IMCC should be cleaned up.
246 Parrot Design Document: documents that describe the features parrot must
249 See also L<pdds/pdd00_pdd>.
253 Parrot Grammar Engine.
259 Pugs' Intermediate Language.
263 Parrot Intermediate Representation: A medium-level assembly language for Parrot
264 that hides messy details like register allocation so language compiler writers
265 who target Parrot don't have to roll their own. Files have the
270 Parrot Magic Cookie: these classes are the primitives that
271 HLLs use to represent their fundamental types, such as Perl's
276 (Perl's) Plain Old Documentation: the preferred form for all kinds of
277 documentation in Parrot. See L<perlpod> for details.
281 Parrot Opcode Syntax Tree: A set of classes that represent opcodes.
285 =item Predereferencing
288 XXX This section needs to be edited down.
290 A bytecode transformation technique which reduces the amount of pointer
291 dereferencing done in the inner loop of the interpreter by pre-converting
292 opcode numbers into pointers to their opfuncs, and also converting the register
293 numbers and constant numbers in the arguments to the ops into pointers.
295 The original implementation by Gregor Purdy was posted on 2001-12-11. On one
296 test system, it resulted in a 22% speed increase on a test program with a tight
299 L<http://archive.develooper.com/perl6-internals@perl.org/msg06941.html>
301 On 2001-12-18, predereferencing got a speed boost (to about 47% faster than the
302 regular DO_OP inner loop -- without compiler optimizations turned on). This was
303 due to an off-list (actually over lunch) suggestion by John Kennedy that
304 instead of pre-initializing the new copy of the bytecode with NULL pointers, we
305 pre-initialize it with pointers to a pseudo-opfunc that does the
306 predereferencing whenever it is encountered.
308 On 2002-04-11, Jason Gloudon suggested combining aspects of the Computed Goto
309 Core and the Prederef[erencing] Core.
311 L<http://archive.develooper.com/perl6-internals@perl.org/msg07064.html>
313 The week of 2003-02-09, Leopold Toetsch combined Computed Goto and
314 Predereferencing to produce the CGP core.
316 L<http://dev.perl.org/perl6/list-summaries/2003/p6summary.2003-02-09.html#Week_of_the_alternative_runloops>
318 Later, on 2003-02-14, Leopold Totsch and Nicholas Clark combined the JIT and
319 the Computed Goto Prederef cores to great effect.
321 L<http://www.perl.com/pub/a/2003/02/p6pdigest/20030216.html>
325 aka run loop, aka runcore. The way Parrot executes PBCs.
326 See L<running.pod> for a list of available runcores, and how to tell
327 parrot which one to use.
331 Simple Meta Object Protocol: A prototype object model written in PIR.
335 Tree Grammar Engine: a tool that can be used to generate tree transformers.
339 A table of operations attached to some data types, such as PMCs and strings.
340 Vtables are used to avoid using switches or long C<if> chains to handle
341 different data types. They're similar to method calls, except that their names
342 are pre-selected, and there is no direct way to invoke them from PIR.
344 =item Warnock's Dilemma
346 The dilemma you face when posting a message to a public forum about something
347 and not even getting an acknowledgment of its existence. This leaves you
348 wondering if your problem is unimportant or previously addressed, if everyone's
349 waiting on someone else to answer you, or if maybe your mail never actually
350 made it to anyone else in the forum.