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 when you have 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 you return 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 you call 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.