home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / arch / 11965 < prev    next >
Encoding:
Text File  |  1992-12-28  |  1.2 KB  |  28 lines
  1. Path: sparky!uunet!news.gtech.com!noc.near.net!transfer.stratus.com!sw.stratus.com!dswartz
  2. From: dswartz@sw.stratus.com (Dan Swartzendruber)
  3. Newsgroups: comp.arch
  4. Subject: Re: branch-and-link
  5. Date: 28 Dec 1992 04:49:40 GMT
  6. Organization: Stratus Computer, Inc.
  7. Lines: 15
  8. Distribution: world
  9. Message-ID: <1hm114INN6v2@transfer.stratus.com>
  10. References: <1hkqk3INNsns@transfer.stratus.com> <1hlll9INNe0s@uwm.edu> <1hm0cpINN8nf@darkstar.UCSC.EDU>
  11. NNTP-Posting-Host: redondo.sw.stratus.com
  12.  
  13. On a related note (vis-a-vis debugging ease) to the branch-and-link issue, another peeve
  14. I've always had is that no commercially available processors (that I know of) make NULL
  15. pointer detection easy withou serious run-time overhead.  Various OS's try by unmapping
  16. the first N pages of memory, which works fine until you run into a chip like the 68030,
  17. which supports huge displacements.  Not to mention if the index register pushes the
  18. effective address out of your protected window, you're hosed.  If you have a standard
  19. base_reg+index_reg+disp format, it would seem to me that having the processor check the
  20. base register for NULL and faulting if it is wouldn't be that hard (or inefficient).
  21. Especially if NULL happens to be zero on that machine.
  22.  
  23. -- 
  24.  
  25. #include <std_disclaimer.h>
  26.  
  27. Dan S.
  28.