note_on_reg_wins 1.5 KB

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