Avoid informal usage of 'you'
This commit is contained in:
parent
7aa5a39735
commit
78ca80f4d5
|
@ -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
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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:
|
||||
|
|
Loading…
Reference in a new issue