doc/sparc/note_on_reg_wins

   1 When developing a fast compiler for the Sun-4 series we have encountered
   2 rather strange behavior of the Sun kernel.
   3
   4 The problem is that with lots of nested procedure calls, (as
   5 is often the case in compilers and parsers) the registers fill up which
   6 causes a kernel trap. The kernel will then write out some of the registers
   7 to memory to make room for another window. When returning from the nested
   8 procedure call, just the reverse happens: yet another kernel trap so the
   9 kernel can load the register from memory.
  10
  11 Unfortunately the kernel only saves or loads a single window (= 16 register)
  12 on each trap. This means that when calling a procedure recursively it causes
  13 a kernel trap on almost every invocation (except for the first few).
  14
  15 To illustrate this consider the following little program:
  16
  17 --------------- little program -------------
  18 f(i)    /* calls itself i times */
  19 int i;
  20 {
  21   if (i)
  22         f(i-1);
  23 }
  24
  25 main(argc, argv)
  26 int argc;
  27 char *argv[];
  28 {
  29
  30
  31   i = atoi(argv[1]);    /* # loops */
  32   j = atoi(argv[2]);    /* depth */
  33
  34   while (i--)
  35         f(j);
  36 }
  37 ------------ end of little program -----------
  38
  39
  40 The performance decreases abruptly when the depth (j) becomes larger
  41 than 5. On a SPARC station we got the following results:
  42
  43         depth   run time (in seconds)
  44
  45         1        0.5
  46         2        0.8
  47         3        1.0
  48         4        1.4    <- from here on it's +6 seconds for each
  49         5        7.6            step deeper.
  50         6       13.9
  51         7       19.9
  52         8       26.3
  53         9       32.9
  54
  55 Things would be a lot better when instead of just 1, the kernel would
  56 save or restore 4 windows (= 64 registers = 50% on our SPARC stations).
  57
  58         -Raymond.