|
|
@@ -2800,7 +2800,7 @@ rdi rsi rdx rcx r8 r9
|
|
|
\end{lstlisting}
|
|
|
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
|
|
|
+arguments. However, in Chapter~\ref{ch:functions} we arrange never to
|
|
|
need more than six arguments. For now, the only function we care about
|
|
|
is \code{read\_int} and it takes zero arguments.
|
|
|
%
|
|
|
@@ -2813,7 +2813,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
|
|
|
@@ -2827,16 +2827,16 @@ 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-Rvar}). Second, when we
|
|
|
build the interference graph (Section~\ref{sec:build-interference}),
|
|
|
@@ -3161,7 +3161,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 location 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
|
|
|
@@ -3405,7 +3405,7 @@ allocation, 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
|
|
|
@@ -7651,7 +7651,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
|
Jeremy Siek