Finish merge.

book.tex

@@ -2800,7 +2800,7 @@ If there are more than six arguments, then the convention is to use
 space on the frame of the caller for the rest of the
 arguments. However, in Chapter~\ref{ch:functions} we arrange to never
 need more than six arguments. For now, the only function we care about
-is \code{read\_int} and it takes zero argument.
+is \code{read\_int} and it takes zero arguments.
 %
 The register \code{rax} is for the return value of a function.
 
@@ -2811,7 +2811,7 @@ example from the caller point of view and then from the callee point
 of view.
 
 The program makes two calls to the \code{read} function.  Also, the
-variable \code{x} is in-use during the second call to \code{read}, so
+variable \code{x} is in use during the second call to \code{read}, so
 we need to make sure that the value in \code{x} does not get
 accidentally wiped out by the call to \code{read}.  One obvious
 approach is to save all the values in caller-saved registers to the
@@ -2825,16 +2825,16 @@ location in the first place. Or better yet, if we can arrange for
 \code{x} to be placed in a callee-saved register, then it won't need
 to be saved and restored during function calls.
 
-The approach that we recommend for variables that are in-use during a
+The approach that we recommend for variables that are in use during a
 function call is to either assign them to callee-saved registers or to
 spill them to the stack. On the other hand, for variables that are not
-in-use during a function call, we try the following alternatives in
+in use during a function call, we try the following alternatives in
 order 1) look for an available caller-saved register (to leave room
 for other variables in the callee-saved register), 2) look for a
 callee-saved register, and 3) spill the variable to the stack.
 
 It is straightforward to implement this approach in a graph coloring
-register allocator. First, we know which variables are in-use during
+register allocator. First, we know which variables are in use during
 every function call because we compute that information for every
 instruction (Section~\ref{sec:liveness-analysis-r1}). Second, when we
 build the interference graph (Section~\ref{sec:build-interference}),
@@ -3145,7 +3145,7 @@ locations if they are live at the same time, that is, if they
 interfere with each other.
 
 An obvious way to compute the interference graph is to look at the set
-of live locations between each instruction and add an edge to the graph
+of live locations between each instruction and the next and add an edge to the graph
 for every pair of variables in the same set.  This approach is less
 than ideal for two reasons. First, it can be expensive because it
 takes $O(n^2)$ time to consider at every pair in a set of $n$ live
@@ -3391,7 +3391,7 @@ such as \code{rax}, are assigned to negative integers. In particular,
 we assign $-1$ to \code{rax} and $-2$ to \code{rsp}.
 
 %% One might wonder why we include registers at all in the liveness
-%% analysis and interference graph, for example, we never allocate a
+%% analysis and interference graph.  For example, we never allocate a
 %% variable to \code{rax} and \code{rsp}, so it would be harmless to
 %% leave them out.  As we see in Chapter~\ref{ch:tuples}, when we begin
 %% to use register for passing arguments to functions, it will be
@@ -7434,7 +7434,7 @@ If there are
 more than six arguments, then the convention is to use space on the
 frame of the caller for the rest of the arguments. However, to ease
 the implementation of efficient tail calls
-(Section~\ref{sec:tail-call}), we arrange to never need more than six
+(Section~\ref{sec:tail-call}), we arrange never to need more than six
 arguments.
 %
 Also recall that the register \code{rax} is for the return value of