perl.cvs.parrot
[Top] [All Lists]

[svn:parrot] r33636 - trunk/docs/book

Subject: [svn:parrot] r33636 - trunk/docs/book
From:
Date: Sun, 7 Dec 2008 13:42:33 -0800 PST
Newsgroups: perl.cvs.parrot

Author: fperrad
Date: Sun Dec  7 13:42:31 2008
New Revision: 33636

Modified:
   trunk/docs/book/ch05_pasm.pod
   trunk/docs/book/ch11_pmcs.pod
   trunk/docs/book/ch12_opcodes.pod

Log:
[book]
- fix typo
- remove trailing space

Modified: trunk/docs/book/ch05_pasm.pod
==============================================================================
--- trunk/docs/book/ch05_pasm.pod       (original)
+++ trunk/docs/book/ch05_pasm.pod       Sun Dec  7 13:42:31 2008
@@ -370,7 +370,7 @@
 Binary opcodes have two source arguments and a destination argument.
 As we mentioned before, most binary math opcodes have a two-argument
 form in which the first argument is both a source and the destination.
-Parrot provides C<add>X<add opcode (PASM)> (addition), 
+Parrot provides C<add>X<add opcode (PASM)> (addition),
 C<sub>X<sub opcode (PASM)> (subtraction), C<mul>X<mul opcode (PASM)>
 (multiplication), C<div>X<div opcode (PASM)> (division), and C<pow>X<pow
 opcode (PASM)> (exponent) opcodes, as well as two different modulus
@@ -1101,7 +1101,7 @@
 Logical operations are implemented for integers and PMCs. Numeric
 values are false if they're 0, and true otherwise. Strings are false
 if they're the empty string or a single character "0", and true
-otherwise. PMCs are true when their 
+otherwise. PMCs are true when their
 C<get_bool>X<get_bool vtable method (PASM)> vtable method returns a
 nonzero value.
 
@@ -1142,7 +1142,7 @@
   not P0, P1
 
 The X<bitwise;opcodes (PASM)> bitwise opcodes operate on their values
-a single bit at a time. C<band>X<band opcode (PASM)>, 
+a single bit at a time. C<band>X<band opcode (PASM)>,
 C<bor>X<bor opcode (PASM)>, and C<bxor>X<bxor opcode (PASM)> return a
 value that is the logical AND, OR, or XOR of each bit in the source
 arguments. They each take a destination register and two source
@@ -1210,7 +1210,7 @@
 
 X<PMCs (Parrot Magic Cookies);arrays>
 The C<Array>X<Array PMC> PMC is an ordered aggregate with
-zero-baed integer keys. The syntax for X<keyed access to PMCs> keyed access to 
a
+zero-based integer keys. The syntax for X<keyed access to PMCs> keyed access 
to a
 PMC puts the key in square brackets after the register name:
 
   new P0, "Array"     # obtain a new array object
@@ -1234,7 +1234,7 @@
 allocation (how much storage the array provides) from the actual
 element count. The currently proposed syntax uses C<set> to set or
 retrieve the allocated size of an array, and an C<elements>
-X<elements opcode (PASM)> opcode to set or retreive the count of
+X<elements opcode (PASM)> opcode to set or retrieve the count of
 elements stored in the array.
 
   set P0, 100         # allocate store for 100 elements
@@ -1731,7 +1731,7 @@
 Z<CHP-5-SECT-6.2.1>
 
 To store a lexical variable in the current scope pad, use C<store_lex>.
-Likewise, use C<find_lex> to retrieve a variable from the current pad pad.
+Likewise, use C<find_lex> to retrieve a variable from the current pad.
 
   new P0, "Int"            # create a variable
   set P0, 10               # assign value to it
@@ -2494,9 +2494,9 @@
     invokecc
     end
 
-Subroutines marked with C<@LOAD> run as soon as they're loaded (before
+Subroutines marked with C<:load> run as soon as they're loaded (before
 C<load_bytecode> returns), rather than waiting to be called. A
-subroutine marked with C<@MAIN> will always run first, no matter what
+subroutine marked with C<:main> will always run first, no matter what
 name you give it or where you define it in the file.
 
   # file3.pasm
@@ -3140,7 +3140,7 @@
 #  Tables
 #  ......
 #  A 2x2 table with top header row looks like this:
-#  
+#
 #  =begin table An Example Table
 #  =headrow
 #  =row

Modified: trunk/docs/book/ch11_pmcs.pod
==============================================================================
--- trunk/docs/book/ch11_pmcs.pod       (original)
+++ trunk/docs/book/ch11_pmcs.pod       Sun Dec  7 13:42:31 2008
@@ -79,7 +79,7 @@
       /* Attributes defined here */
 
       /* VTABLE and METHODs defined here. */
-  
+
   }
 
 The C<extends> keyword is optional, but allows us to specify that this
@@ -116,7 +116,7 @@
   pmclass Foo {
     ATTR INTVAL bar;
        ATTR PMC baz;
-       
+
        ...
   }
 
@@ -128,7 +128,7 @@
   attrs->baz = pmc_new( ... )     /* It's a PMC */
 
 Notice how the type name of the attributes structure is C<Parrot_>,
-followed by the name of the PMC with the same capitalzation as is used
+followed by the name of the PMC with the same capitalization as is used
 in the C<pmclass> definition, followed by C<_Attributes>. The macro to
 return this structure is C<PARROT_> followed by the name of the PMC in
 all caps.
@@ -294,7 +294,7 @@
 #  Tables
 #  ......
 #  A 2x2 table with top header row looks like this:
-#  
+#
 #  =begin table An Example Table
 #  =headrow
 #  =row

Modified: trunk/docs/book/ch12_opcodes.pod
==============================================================================
--- trunk/docs/book/ch12_opcodes.pod    (original)
+++ trunk/docs/book/ch12_opcodes.pod    Sun Dec  7 13:42:31 2008
@@ -9,7 +9,7 @@
 are individual instructions that implement low-level operations in Parrot N<In 
the
 world of microprocessors, the word "opcode" typically refers to the numeric 
identifier
 for each instructions. The human-readable word used in the associated assembly 
language
-is called the "mnemonic". An assembler, among other tasks, is responsble for 
converting
+is called the "mnemonic". An assembler, among other tasks, is responsible for 
converting
 mnemonics into opcodes for execution. In Parrot, instead of referring to an 
instruction
 by different names depending on what form it's in, we just call them all 
"opcodes">. Of
 course the list of things that qualify as "low-level" in Parrot can be pretty 
advanced
@@ -35,8 +35,8 @@
 only available as optimizations in certain compilers, some are intended for 
general use,
 and some are just interesing flights of fancy with no practical benefits. One 
runcore that
 we've already seen is the debugging runcore which prompts the user for 
commands between
-executing each opcode. Another valuable mainteance runcore is the GC dubug 
core (which runs a
-full sweep of the garbage collector between each opcode). 
+executing each opcode. Another valuable maintenance runcore is the GC dubug 
core (which runs a
+full sweep of the garbage collector between each opcode).
 
 =over 4
 
@@ -47,7 +47,7 @@
 to be called by the core. The slow core performs bounds checking to ensure 
that the next
 opcode to be called is properly in bounds. Because of this modular approach 
where opcodes
 are treated as separate executable entities many other runcores, especially 
diagnostic and
-maintenance cores are based on this design. 
+maintenance cores are based on this design.
 
 =item* Fast Core
 
@@ -57,7 +57,7 @@
 =item* Computed Goto Core
 
 I<Computed Goto> is a feature of some C compilers where a label is treated as 
a piece of
-data that can be stored in an array. Each opcode is simply a lable in a very 
large
+data that can be stored in an array. Each opcode is simply a label in a very 
large
 function, and the labels are stored in an array. Calling an opcode is as easy 
as taking
 that opcode's number as the index of the label array, and calling the 
associated label.
 Sound complicated? It is a little, especially to C programmers who are not 
used to these
@@ -105,7 +105,7 @@
 
 =head3 Opcode Control Flow
 
-=head2 The Opcode Compiler 
+=head2 The Opcode Compiler
 
 =head2 Dynops
 
@@ -176,7 +176,7 @@
 #  Tables
 #  ......
 #  A 2x2 table with top header row looks like this:
-#  
+#
 #  =begin table An Example Table
 #  =headrow
 #  =row

<Prev in Thread] Current Thread [Next in Thread>
  • [svn:parrot] r33636 - trunk/docs/book, fperrad <=