home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / arch / 12009 < prev    next >
Encoding:
Internet Message Format  |  1992-12-30  |  2.2 KB
  1. Path: sparky!uunet!auspex-gw!guy
  2. From: guy@Auspex.COM (Guy Harris)
  3. Newsgroups: comp.arch
  4. Subject: Re: branch-and-link
  5. Message-ID: <16171@auspex-gw.auspex.com>
  6. Date: 30 Dec 92 23:32:07 GMT
  7. References: <1hlll9INNe0s@uwm.edu> <1hm0cpINN8nf@darkstar.UCSC.EDU> <1hm114INN6v2@transfer.stratus.com>
  8. Sender: news@auspex-gw.auspex.com
  9. Organization: Auspex Systems, Santa Clara
  10. Lines: 36
  11. Nntp-Posting-Host: auspex.auspex.com
  12.  
  13. >On a related note (vis-a-vis debugging ease) to the branch-and-link
  14. >issue, another peeve I've always had is that no commercially available
  15. >processors (that I know of) make NULL pointer detection easy withou
  16. >serious run-time overhead.  Various OS's try by unmapping the first N
  17. >pages of memory, which works fine until you run into a chip like the
  18. >68030, which supports huge displacements. 
  19.  
  20. The 68030 is no different from most other processors here; it's
  21. *identical*, of course, to the 68020 in that respect, and even the
  22. earlier 68K's had 16-bit displacements.
  23.  
  24. Besides, on processors that *don't* have long displacements, the code
  25. that's generated by programmers or compilers generally synthesizes them
  26. with additions, or something such as that, in any case, so the size of
  27. the displacement is irrelevant.
  28.  
  29. However, if 99 44/100% of all the references through a pointer use
  30. displacements less than about 8K or so - and all the code *I've* seen
  31. backs that assumption up, as very little of it has large displacements -
  32. you can get 99 44/100% coverage.
  33.  
  34. >Not to mention if the index register pushes the effective address out
  35. >of your protected window, you're hosed.
  36.  
  37. That's the same issue as the displacement issue; it has nothing to do
  38. with your addressing modes, it has to do with how large the object
  39. pointed to by the pointer in question are.
  40.  
  41. >If you have a standard base_reg+index_reg+disp format, it would seem to
  42. >me that having the processor check the base register for NULL and
  43. >faulting if it is wouldn't be that hard (or inefficient).
  44.  
  45. You *don't* always have that format.  And, given my admittedly scanty
  46. knowledge about modern processors, I'm loath to assume that having the
  47. processor do such a check wouldn't be that inefficient; it won't seem
  48. that way to *me* unless at least one processor architect says so....
  49.