home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / arch / 9082 < prev    next >
Encoding:
Internet Message Format  |  1992-08-29  |  3.0 KB
  1. Path: sparky!uunet!gatech!darwin.sura.net!uvaarpa!gems.vcu.edu!fritz
  2. From: fritz@gems.vcu.edu (Fritz)
  3. Newsgroups: comp.arch
  4. Subject: Re: trapping speculative ops
  5. Message-ID: <1992Aug28.123840.87@gems.vcu.edu>
  6. Date: 28 Aug 92 12:38:39 -0400
  7. References: <GLEW.92Aug25180333@pdx007.intel.com> <CLIFFC.92Aug27082745@medea.rice.edu>
  8. Organization: Medical College of Virginia
  9. Lines: 60
  10.  
  11. In article <CLIFFC.92Aug27082745@medea.rice.edu>, 
  12.   cliffc@rice.edu (Cliff Click) writes:
  13.  
  14. [...]
  15. > <Cliff Click>
  16. > || Let every register have some extra "trap" bits.
  17. > || A read of the register with it's trap bits set, causes the exception.
  18. > || A write to the register sets the trap bits according to the success of
  19. > || the operation.
  20. > || 
  21. > || With this design, exceptions are triggered at the START of some operation,
  22. > || instead of in the middle of it.
  23. > 
  24. > <Stanley T.H. Chow>
  25. > | Very nice model, but what to do about saving and restoring registers
  26. > | across subroutine call, interupts, etc.?
  27. > 
  28. > <Cliff Click>
  29. > Soft answer:
  30. > The compiler knows that live and possibly dangerous results cannot be 
  31. > carried across a subroutine call.  Therefore it uses every possibly 
  32. > dangerous result before the subroutine call.  This means you cannot 
  33. > lift that divide-by-zero across the subroutine call.
  34. > 
  35. > Hard answer:
  36. > The hardware allows these bits to be read and written using a special 
  37. > register.  The special register can be "slow" because it's assumed to be
  38. > an infrequent operation.  The trap bits are saved and restored along with
  39. > the registers.
  40. > 
  41. > Interrupts appear to require the "hard answer", but there is another way
  42. > (albeit possible worse):
  43. > 
  44. > Harder Soft answer:
  45. > Only 1 interruptable condition can exist at a time.  The compiler forces the
  46. > issue by using the possible dangerous register before it allows another 
  47. > operation which can cause a dangerous register.  External interrupts are
  48. > disabled while a dangerous register exists.  The compiler ensures that no
  49. > register is kept dangerous for longer than the desired interrupt latency.
  50. > Since only 1 interrupt can occur at a time, no trap bits need to be saved
  51. > or restored.
  52. > Scheduling restrictions in this answer are probably worse than implementing 
  53. > the hardware solution.  I have no idea what you can implement cheaply in
  54. > hardware.
  55. > 
  56. [...]
  57. > Stanley Chow            schow@BNR.CA
  58. > Cliff Click             cliffc@cs.rice.edu
  59. [...]
  60.  
  61. A hardware answer for interrupts only that might be easier to implement
  62. would be to say that during interrupt service, the trap bits are not set
  63. on writes, and are ignored on reads.  Any operation that would
  64. ordinarily trap is undefined during interrupt service: it might put
  65. garbage in the register, (possibly _after_ returning from the interrupt).
  66. You'd have to be pretty confident that the interrupt routines didn't
  67. divide by zero and so forth--but you have to be pretty confident in the
  68. correctness of your interrupt routines with any architecture.
  69.  
  70. You'd use the software answer for subroutine calls.
  71.