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
