Avoid informal usage of 'you'

This commit is contained in:
ceriel
1991-11-19 13:37:20 +00:00
parent 7aa5a39735
commit 78ca80f4d5
7 changed files with 13 additions and 13 deletions

View File

@@ -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

View File

@@ -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

View File

@@ -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: