home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / arch / 11959 < prev    next >
Encoding:
Internet Message Format  |  1992-12-27  |  2.5 KB
  1. Path: sparky!uunet!zaphod.mps.ohio-state.edu!uwm.edu!csd4.csd.uwm.edu!jgd
  2. From: jgd@csd4.csd.uwm.edu (John G Dobnick)
  3. Newsgroups: comp.arch
  4. Subject: Re: branch-and-link
  5. Date: 28 Dec 1992 01:35:37 GMT
  6. Organization: University of Wisconsin - Milwaukee
  7. Lines: 41
  8. Message-ID: <1hlll9INNe0s@uwm.edu>
  9. References: <1hkqk3INNsns@transfer.stratus.com>
  10. Reply-To: jgd@csd4.csd.uwm.edu
  11. NNTP-Posting-Host: 129.89.7.4
  12. Originator: jgd@csd4.csd.uwm.edu
  13.  
  14. From article <1hkqk3INNsns@transfer.stratus.com>, by dswartz@sw.stratus.com (Dan Swartzendruber):
  15. > Here's a question for the hardware types: is there any reason either of
  16. > design complexity or performance to not have *all* branches (conditional
  17. > and unconditional) save their origin somewhere (probably in a fast
  18. > dedicated register)? 
  19.  
  20. Can't speak to the hardware complexity, but it _has_ been done.
  21.  
  22. The Unisys (formerly Univac) 1100 series machines did this.   Various
  23. models saved the last "n" jump locations ("n" being model dependent)
  24. in part of the fast register stack.  I believe the minimum value
  25. of n was 4.   Even this much "jump history" was quite useful in
  26. debugging certain types of program failure.  (What is saved is the
  27. value of the program counter when the jump is executed -- this is
  28. usually one past the actual jump.  For conditional jumps, this
  29. address is saved only if the jump is taken.)
  30.  
  31. I'm not quite sure what the specs are on the more recent models of the
  32. 2200 series machines (successors to the 1100's), but I think they 
  33. save at least 8 previous jump locations. 
  34.  
  35. The Operating system also has the facility to detect "jump history
  36. full" conditions and trap to a routine to save these values in main
  37. memory.  This allows the OS to maintain a much longer jump history --
  38. useful for OS debugging -- at the cost of lessened system performance.
  39.  
  40. Except for the "special" use of this in OS debugging, there was _no_
  41. performance hit for the feature.  In fact, it was always "on" for
  42. normal user code.  When the jump history filled, it "wrapped".   There
  43. was a hardware status bit set to flag where the "oldest" of the 
  44. history entries was, so one could make sense of them.
  45.  
  46. All in all, a _quite_ useful feature.  More machines should have it!
  47.  
  48. -- 
  49. John G Dobnick                          ATTnet: (414) 229-5727
  50. Computing Services Division             INTERNET: jgd@uwm.edu
  51. University of Wisconsin - Milwaukee     UUCP: uunet!uwm!jgd
  52.  
  53. "Knowing how things work is the basis for appreciation,
  54. and is thus a source of civilized delight."  -- William Safire
  55.