diff --git a/doc/ego/cf/cf4 b/doc/ego/cf/cf4
index ca19394df..843a41117 100644
--- a/doc/ego/cf/cf4
+++ b/doc/ego/cf/cf4
@@ -15,8 +15,8 @@ that can reach B without going through C.
 .PP
 As an example of how the algorithm works,
 consider the piece of program of Fig. 4.1.
-First just look at the program and think for
-yourself what part of the code constitutes the loop.
+First just look at the program and try to
+see what part of the code constitutes the loop.
 .DS
 loop
    if cond then                       1
diff --git a/doc/ego/cs/cs4 b/doc/ego/cs/cs4
index c8eef93f5..c0a42d5fc 100644
--- a/doc/ego/cs/cs4
+++ b/doc/ego/cs/cs4
@@ -133,7 +133,7 @@ l l.
 .DE
 In this way an item on the fake-stack always contains
 the necessary information.
-As you see, EM expressions are parsed bottum up.
+EM expressions are parsed bottum up.
 .NH 3
 Updating entities
 .PP
diff --git a/doc/occam/p2 b/doc/occam/p2
index be203db28..b7003a6b6 100644
--- a/doc/occam/p2
+++ b/doc/occam/p2
@@ -91,8 +91,8 @@ list:
 .DE
 Again, the \fB``%while''\fP is only used in case of a conflict.
 .LP
-Error recovery is done almost completely automatically. All you have to do
-is to write a routine called \fILLmessage\fP to give the necessary error
+Error recovery is done almost completely automatically. All the LLgen-user has to do
+is write a routine called \fILLmessage\fP to give the necessary error
 messages and supply information about terminals found missing.
 .NH 2	
 Indentation
diff --git a/doc/occam/p4 b/doc/occam/p4
index 7446d8941..afa9ec106 100644
--- a/doc/occam/p4
+++ b/doc/occam/p4
@@ -12,7 +12,7 @@ File inclusion
 .PP
 The C preprocessor is applied to the input file before
 compilation, so that files containing useful \fBPROC\fP and \fBDEF\fP
-declarations can be used in your program by using the \fB#include\fP-directive
+declarations can be used in the program by using the \fB#include\fP-directive
 of the preprocessor.
 .NH 2
 Substitution
@@ -32,8 +32,8 @@ an input or output process. Thus,
 .ft
 .DE
 is not allowed. Because it was easy to add, and it was used by some programs,
-our compiler allows it. (If you prefer portability you are advised not to make
-use of it.)
+our compiler allows it. (If portability is an issue, usage of this feature
+is not advisable).
 .NH 2
 Configuration
 .PP
diff --git a/doc/sparc/2 b/doc/sparc/2
index 2421ca36f..5067e987c 100644
--- a/doc/sparc/2
+++ b/doc/sparc/2
@@ -48,7 +48,7 @@ provided extremely high performance. All register-to-register operations
 require exactly one clock cycle, and all register-to-memory and
 memory-to-register operations require two clock cycles, one to retrieve
 the instruction and one to access external memory. At a clock speed of
-over 20 MHz this means that you can achieve well over 10 VAX MIPS:
+over 20 MHz this means that well over 10 VAX MIPS can be achieved:
 more than 4 times the speed of a 15 MHz 68020 used in the Sun3/50.
 .PP
 As above, the reader should also have some general knowledge about
diff --git a/doc/sparc/3 b/doc/sparc/3
index 6dd213443..26be8682b 100644
--- a/doc/sparc/3
+++ b/doc/sparc/3
@@ -65,7 +65,7 @@ peculiarities of the SPARC processor and Sun's C-compiler (henceforth
 simply called \fIcc\fR).
 .PP
 For some reason, the SPARC stack pointer requires alignment
-on 8 bytes, so you cannot push a 4-byte integer on the stack
+on 8 bytes, so it is impossible to push a 4-byte integer on the stack
 and then \*(Sisub 4, %sp\*(So\(dd.
 .FS
 \(dd For more information about SPARC assembler see the Sun-4 Assembly
diff --git a/doc/sparc/note_on_reg_wins b/doc/sparc/note_on_reg_wins
index 7f045b83f..c2927c1e1 100644
--- a/doc/sparc/note_on_reg_wins
+++ b/doc/sparc/note_on_reg_wins
@@ -1,15 +1,15 @@
 When developing a fast compiler for the Sun-4 series we have encountered
 rather strange behavior of the Sun kernel.
 
-The problem is that when you have lots of nested procedure calls, (as
+The problem is that with lots of nested procedure calls, (as
 is often the case in compilers and parsers) the registers fill up which
 causes a kernel trap. The kernel will then write out some of the registers
-to memory to make room for another window. When you return from the nested
+to memory to make room for another window. When returning from the nested
 procedure call, just the reverse happens: yet another kernel trap so the
 kernel can load the register from memory.
 
 Unfortunately the kernel only saves or loads a single window (= 16 register)
-on each trap. This means that when you call a procedure recursively it causes
+on each trap. This means that when calling a procedure recursively it causes
 a kernel trap on almost every invocation (except for the first few).
 
 To illustrate this consider the following little program: