ack/doc/sparc/note_on_reg_wins

59 lines
1.5 KiB
Plaintext
Raw Normal View History

1991-09-27 16:19:24 +00:00
When developing a fast compiler for the Sun-4 series we have encountered
rather strange behavior of the Sun kernel.
1991-11-19 13:37:20 +00:00
The problem is that with lots of nested procedure calls, (as
1991-09-27 16:19:24 +00:00
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
1991-11-19 13:37:20 +00:00
to memory to make room for another window. When returning from the nested
1991-09-27 16:19:24 +00:00
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)
1991-11-19 13:37:20 +00:00
on each trap. This means that when calling a procedure recursively it causes
1991-09-27 16:19:24 +00:00
a kernel trap on almost every invocation (except for the first few).
To illustrate this consider the following little program:
--------------- little program -------------
f(i) /* calls itself i times */
int i;
{
if (i)
f(i-1);
}
main(argc, argv)
int argc;
char *argv[];
{
i = atoi(argv[1]); /* # loops */
j = atoi(argv[2]); /* depth */
while (i--)
f(j);
}
------------ end of little program -----------
The performance decreases abruptly when the depth (j) becomes larger
than 5. On a SPARC station we got the following results:
depth run time (in seconds)
1 0.5
2 0.8
3 1.0
4 1.4 <- from here on it's +6 seconds for each
5 7.6 step deeper.
6 13.9
7 19.9
8 26.3
9 32.9
Things would be a lot better when instead of just 1, the kernel would
save or restore 4 windows (= 64 registers = 50% on our SPARC stations).
-Raymond.