home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / arch / 9074 < prev    next >
Encoding:
Text File  |  1992-08-27  |  2.9 KB  |  66 lines
  1. Newsgroups: comp.arch
  2. Path: sparky!uunet!zaphod.mps.ohio-state.edu!cs.utexas.edu!torn!cunews!nrcnet0!bnrgate!bmerh85!bcars64a!bqneh3!schow
  3. From: schow@bqneh3.bnr.ca (Stanley T.H. Chow)
  4. Subject: Program behaviour (was Re: trapping speculative ops
  5. Message-ID: <1992Aug27.202845.10747@bcars64a.bnr.ca>
  6. Sender: news@bcars64a.bnr.ca (Usenet News)
  7. Organization: Bell Northern Research Ltd, Ottawa
  8. References: <l9q6e0INN919@exodus.Eng.Sun.COM>
  9. Date: Thu, 27 Aug 1992 20:28:45 GMT
  10. Lines: 54
  11.  
  12. In article <l9q6e0INN919@exodus.Eng.Sun.COM> chased@rbbb.Eng.Sun.COM (David Chase) writes:
  13. >As far as loads and stores go, I am similarly mystified by the
  14. >insistence that each and every trap from the source program be
  15. >preserved in "very-optimized" code (not code compiled for debugging,
  16. >or at a "normal" level of optimization).
  17.  
  18. Some people (including me), believe that there is only *one* level
  19. of optimization. One should always ship the same binary that one
  20. tested; doing otherwise expresses immense faith in the ability of
  21. one's process to recompile the same source as well as the correctness
  22. of ones tools - the compilers, optimizes, linkers.
  23.  
  24. And then there are people who have to debug "very-optimized" code
  25. because the program must interact with the outside world. E.g., when
  26. writing a driver for gigabit per seond device, and the CPU chip can
  27. barely keep up, how do you not debug "very-optimized" code?
  28.  
  29. Also, there are languages and systems that actually specify the
  30. behaviour for incorrect programs - typically, trap if dereferencing
  31. a wild pointer. Given that most MMUs do quite a good job, it is 
  32. strange to force those compilers to generate slower code.
  33.  
  34. >For instance, (as has been
  35. >noted by several people before me in more severely refereed forums),
  36. >if page zero is mapped readable, then you can transform
  37. >   [example deleted]
  38. >No hardware support is required, but some other traps might be lost.
  39.  
  40. No hardware support is required in any case. Most systems already 
  41. have an MMU that can map out page zero. The question is whether
  42. the gain in performance justifies the lost in security. I expect
  43. different people will answer differently.
  44.  
  45.  
  46. >Note that the hardware support for what I described above is pretty
  47. >damn cheap.  Note that no changes are needed to the architecture.  
  48.  
  49. I assume you mean no change to "Instruction Set Architecuture". You
  50. are certainly implying changes to "System Architecture".
  51.  
  52. >Remember, we've got tools to help us debug our code.  
  53.  
  54. But only during the "debugging phase". What happens when the program
  55. is released into user hands? OK, for a compiler, you could ask the
  56. user to send you the source files. What if the program controls a 
  57. chemical plant? Are you going to ask the user to ship you a copy of
  58. the plant? Some debugging just *have* to be done on the target system.
  59.  
  60.  
  61. --
  62. Stanley Chow            InterNet: schow@BNR.CA
  63. Bell Northern Research  UUCP:     ..!uunet!bnrgate!bqneh3!schow
  64. (613) 763-2831
  65. Me? Represent other people? Don't make them laugh so hard.
  66.