|
@@ -766,7 +766,7 @@ following grammar.
|
|
|
|
|
|
This chapter concerns the challenge of compiling a subset of Racket,
|
|
This chapter concerns the challenge of compiling a subset of Racket,
|
|
which we name $R_1$, to x86-64 assembly code~\citep{Intel:2015aa}.
|
|
which we name $R_1$, to x86-64 assembly code~\citep{Intel:2015aa}.
|
|
-(Henceforce we shall refer to x86-64 simply as x86). The chapter
|
|
|
|
|
|
+(Hence force we shall refer to x86-64 simply as x86). The chapter
|
|
begins with a description of the $R_1$ language (Section~\ref{sec:s0})
|
|
begins with a description of the $R_1$ language (Section~\ref{sec:s0})
|
|
and then a description of x86 (Section~\ref{sec:x86}). The
|
|
and then a description of x86 (Section~\ref{sec:x86}). The
|
|
x86 assembly language is quite large, so we only discuss what is
|
|
x86 assembly language is quite large, so we only discuss what is
|
|
@@ -3716,7 +3716,7 @@ which we add the $2$, the element at index $0$ of the 1-tuple.
|
|
Figure~\ref{fig:interp-R3} shows the interpreter for the $R_3$
|
|
Figure~\ref{fig:interp-R3} shows the interpreter for the $R_3$
|
|
language. With the addition of the vector operations, there are quite
|
|
language. With the addition of the vector operations, there are quite
|
|
a few primitive operations and the interpreter code for them is
|
|
a few primitive operations and the interpreter code for them is
|
|
-somewhat repetative. In Figure~\ref{fig:interp-R3} we factor out the
|
|
|
|
|
|
+somewhat repetitive. In Figure~\ref{fig:interp-R3} we factor out the
|
|
different parts into the \code{interp-op} function and the similar
|
|
different parts into the \code{interp-op} function and the similar
|
|
parts into the one match clause shown in
|
|
parts into the one match clause shown in
|
|
Figure~\ref{fig:interp-R3}. It is important for that match clause to
|
|
Figure~\ref{fig:interp-R3}. It is important for that match clause to
|
|
@@ -3805,10 +3805,10 @@ goes out of scope prior to the reference.
|
|
t)
|
|
t)
|
|
0)
|
|
0)
|
|
\end{lstlisting}
|
|
\end{lstlisting}
|
|
-From the perspective of programmer-oberservable behavior, tuples live
|
|
|
|
|
|
+From the perspective of programmer-observable behavior, tuples live
|
|
forever. Of course, if they really lived forever, then many programs
|
|
forever. Of course, if they really lived forever, then many programs
|
|
would run out of memory.\footnote{The $R_3$ language does not have
|
|
would run out of memory.\footnote{The $R_3$ language does not have
|
|
- looping or recursive function, so it is nie impossible to write a
|
|
|
|
|
|
+ looping or recursive function, so it is nigh impossible to write a
|
|
program in $R_3$ that will run out of memory. However, we add
|
|
program in $R_3$ that will run out of memory. However, we add
|
|
recursive functions in the next Chapter!} A Racket implementation
|
|
recursive functions in the next Chapter!} A Racket implementation
|
|
must therefore perform automatic garbage collection.
|
|
must therefore perform automatic garbage collection.
|
|
@@ -3874,7 +3874,7 @@ to Cheney~\citep{Cheney:1970aa} for simultaneously representing the
|
|
queue and compacting the objects as they are copied into the ToSpace.
|
|
queue and compacting the objects as they are copied into the ToSpace.
|
|
|
|
|
|
Figure~\ref{fig:cheney} shows several snapshots of the ToSpace as the
|
|
Figure~\ref{fig:cheney} shows several snapshots of the ToSpace as the
|
|
-copy progresses. The queue is represented by a chunk of continguous
|
|
|
|
|
|
+copy progresses. The queue is represented by a chunk of contiguous
|
|
memory at the beginning of the ToSpace, using two pointers to track
|
|
memory at the beginning of the ToSpace, using two pointers to track
|
|
the front and the back of the queue. The algorithm starts by copying
|
|
the front and the back of the queue. The algorithm starts by copying
|
|
all objects that are immediately reachable from the root set into the
|
|
all objects that are immediately reachable from the root set into the
|
|
@@ -3952,7 +3952,7 @@ pointed-to objects will have changed.
|
|
\begin{figure}[tbp]
|
|
\begin{figure}[tbp]
|
|
\centering \includegraphics[width=0.7\textwidth]{shadow-stack}
|
|
\centering \includegraphics[width=0.7\textwidth]{shadow-stack}
|
|
\caption{Changing from just a normal stack to use a root stack
|
|
\caption{Changing from just a normal stack to use a root stack
|
|
- for pointers to fascilitate garbage collection.}
|
|
|
|
|
|
+ for pointers to facilitate garbage collection.}
|
|
\label{fig:shadow-stack}
|
|
\label{fig:shadow-stack}
|
|
\end{figure}
|
|
\end{figure}
|
|
|
|
|
|
@@ -3992,14 +3992,14 @@ interface to the garbage collector. We define a type \code{ptr} for
|
|
64-bit pointers. The function \code{initialize} should create the
|
|
64-bit pointers. The function \code{initialize} should create the
|
|
FromSpace, ToSpace, and root stack. The \code{initialize} function
|
|
FromSpace, ToSpace, and root stack. The \code{initialize} function
|
|
is meant to be called near the beginning of \code{main}, before the
|
|
is meant to be called near the beginning of \code{main}, before the
|
|
-body of the program exectutes. The \code{initialize} function should
|
|
|
|
-put the address of the beginning of the FromStack into the global
|
|
|
|
|
|
+body of the program executes. The \code{initialize} function should
|
|
|
|
+put the address of the beginning of the FromSpace into the global
|
|
variable \code{free\_ptr}. The global \code{fromspace\_end} should
|
|
variable \code{free\_ptr}. The global \code{fromspace\_end} should
|
|
point to the address that is 1-past the end of the FromSpace. The
|
|
point to the address that is 1-past the end of the FromSpace. The
|
|
\code{rootstack\_begin} global should point to the beginning of the
|
|
\code{rootstack\_begin} global should point to the beginning of the
|
|
root stack.
|
|
root stack.
|
|
|
|
|
|
-As long as there is room left in the FromStack, your generated code
|
|
|
|
|
|
+As long as there is room left in the FromSpace, your generated code
|
|
can allocate tuples simply by moving the \code{free\_ptr} forward.
|
|
can allocate tuples simply by moving the \code{free\_ptr} forward.
|
|
The amount of room left in FromSpace is the difference between the
|
|
The amount of room left in FromSpace is the difference between the
|
|
\code{fromspace\_end} and the \code{free\_ptr}. The \code{collect}
|
|
\code{fromspace\_end} and the \code{free\_ptr}. The \code{collect}
|
|
@@ -4202,11 +4202,13 @@ a root and it is live at that point.
|
|
|
|
|
|
In this pass we generate the code for explicitly manipulating the root
|
|
In this pass we generate the code for explicitly manipulating the root
|
|
stack, lower the forms needed for garbage collection, and also lower
|
|
stack, lower the forms needed for garbage collection, and also lower
|
|
-the \code{vector-ref} and \code{vector-set!} forms.
|
|
|
|
-We shall thread a pointer to the top of root stack through the program
|
|
|
|
-in local variables whose names all begin with \code{rootstack}.
|
|
|
|
|
|
+the \code{vector-ref} and \code{vector-set!} forms. We shall thread a
|
|
|
|
+pointer to the top of root stack through the program in local
|
|
|
|
+variables whose names all begin with \code{rootstack}. We recommend
|
|
|
|
+passing the current name of the root stack variable as a parameter to
|
|
|
|
+the \code{select-instructions} function.
|
|
%
|
|
%
|
|
-\marginpar{\tiny I would have prefered that we use a dedicated
|
|
|
|
|
|
+\marginpar{\tiny I would have preferred that we use a dedicated
|
|
register for the top of the root stack. (to do: next year) \\--Jeremy}
|
|
register for the top of the root stack. (to do: next year) \\--Jeremy}
|
|
%
|
|
%
|
|
We shall obtain the top of the root stack to begin with from the
|
|
We shall obtain the top of the root stack to begin with from the
|
|
@@ -4946,8 +4948,11 @@ as the program file name but with \key{.scm} replaced with \key{.s}.
|
|
%% LocalWords: runtime Liveness liveness undirected Balakrishnan je
|
|
%% LocalWords: runtime Liveness liveness undirected Balakrishnan je
|
|
%% LocalWords: Rosen DSATUR SDO Gebremedhin Omari morekeywords cnd
|
|
%% LocalWords: Rosen DSATUR SDO Gebremedhin Omari morekeywords cnd
|
|
%% LocalWords: fullflexible vertices Booleans Listof Pairof thn els
|
|
%% LocalWords: fullflexible vertices Booleans Listof Pairof thn els
|
|
-%% LocalWords: boolean typecheck notq cmpq sete movzbq jmp al
|
|
|
|
|
|
+%% LocalWords: boolean typecheck notq cmpq sete movzbq jmp al xorq
|
|
%% LocalWords: EFLAGS thns elss elselabel endlabel Tuples tuples os
|
|
%% LocalWords: EFLAGS thns elss elselabel endlabel Tuples tuples os
|
|
%% LocalWords: tuple args lexically leaq Polymorphism msg bool nums
|
|
%% LocalWords: tuple args lexically leaq Polymorphism msg bool nums
|
|
%% LocalWords: macosx unix Cormen vec callee xs maxStack numParams
|
|
%% LocalWords: macosx unix Cormen vec callee xs maxStack numParams
|
|
-%% LocalWords: arg
|
|
|
|
|
|
+%% LocalWords: arg bitwise XOR'd thenlabel immediates optimizations
|
|
|
|
+%% LocalWords: deallocating Ungar Detlefs Tene kx FromSpace ToSpace
|
|
|
|
+%% LocalWords: Appel Diwan Siebert ptr fromspace rootstack typedef
|
|
|
|
+%% LocalWords: len prev rootlen heaplen setl lt
|