Avoid informal usage of 'you'
This commit is contained in:
@@ -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:
|
||||
|
||||
Reference in New Issue
Block a user