Minor book issues

[drmikehenry]

Thanks for writing such a useful book to go along with bitvec. It's very well written and makes for enjoyable reading.

Below is a diff showing a few minor changes. I didn't make a pull request as I'm not sure in some of the cases what was actually meant. Please consider the diffs below as an easy way to point at places you may want to adjust.

diff --git a/book/data-structures/bitvec.md b/book/data-structures/bitvec.md
index ef75247..7bc2f90 100644
--- a/book/data-structures/bitvec.md
+++ b/book/data-structures/bitvec.md
@@ -15,7 +15,7 @@ uninteresting.
 
 `BitVec` implements the constructors shown in the standard library: `::new()`
 creates a handle without any allocation, `BitSlice` implements the
-`.to_bitvec()` method, and and `ToOwned` trait, to copy a bit-slice into a new
+`.to_bitvec()` method, and `ToOwned` trait, to copy a bit-slice into a new
 bit-vector. Additionally, the `bitvec!` macro takes all the `bits!` arguments
 and produces an owned allocation instead of a stack temporary. You can also
 construct a `BitVec` by `.collect`ing any iterator of `bool`s.
diff --git a/book/memory-model.md b/book/memory-model.md
index 561a19f..2cee4aa 100644
--- a/book/memory-model.md
+++ b/book/memory-model.md
@@ -375,7 +375,7 @@ and permit an increased (possibly even complete) removal of synchrony guards.
 
 > I am not aware of any processor hardware which fails to guarantee that all
 > bits of memory are fully defined at the clock edges of all instructions that
-> use the location. To the full extent my knowledge, all memory banks in all
+> use the location. To the full extent of my knowledge, all memory banks in all
 > relevant processors have a stable bit-value at the start of a tick, when
 > reads occur, and at the end of a tick, when writes commit. At no point does
 > changing the value of one bit of a memory component affect the electrical
diff --git a/book/performance.md b/book/performance.md
index 18a9ee3..3262bdf 100644
--- a/book/performance.md
+++ b/book/performance.md
@@ -5,7 +5,7 @@ structures. This is an inevitable consequence of the fact that, even on
 architectures that have them, compilers typically do not emit object code
 instructions that access individual bits within a memory location. Therefore,
 each access in `bitvec` has, in addition to a memory operation, one or two
-shift instructions one or two `AND`/`OR`/`NOT` instructions.
+shift instructions and one or two `AND`/`OR`/`NOT` instructions.
 
 This means that, inevitably, `bitvec` is slower in CPU time than `[bool]` is.
 Measurements indicate roughly a factor of ten, but with also about 10x more
diff --git a/book/pointer-encoding.md b/book/pointer-encoding.md
index 190238e..c64f23b 100644
--- a/book/pointer-encoding.md
+++ b/book/pointer-encoding.md
@@ -150,7 +150,7 @@ provided compiler API in `core`.
       Furthermore, this dead region does not exist on 32-bit architectures, x86
       or otherwise, and since `bitvec` explicitly supports 32-bit systems, the
       use of dead bits only present on a subset of supported targets and subject
-      to their own extra rules
+      to their own extra rules [sentence trails off...]
 
 [MMU translation pages]: https://en.wikipedia.org/wiki/X86-64#Virtual_address_space_details
 [constructing values]: https://github.com/rust-lang/rust/blob/8558ccd/src/libcore/slice/mod.rs#L5642-L5739
diff --git a/book/practical-use/bitfields.md b/book/practical-use/bitfields.md
index 095a12e..34ab778 100644
--- a/book/practical-use/bitfields.md
+++ b/book/practical-use/bitfields.md
@@ -71,7 +71,7 @@ complication to the `BitStore` memory model. There is also a second dimension of
 segment ordering. `bitvec` tries to make explicitly clear that the `Lsb0` and
 `Msb0` types refer only to the ordering of *bits* within registers, and not to
 the ordering of *bytes* within registers. However, when the register being
-stored or stored does not fit within one register of the storage `BitSlice`, it
+stored does not fit within one register of the storage `BitSlice`, it
 must be split into multiple segments, and those segments must somehow be ordered
 in memory.