home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / arch / 12019 < prev    next >
Encoding:
Text File  |  1992-12-31  |  1.9 KB  |  46 lines
  1. Newsgroups: comp.arch
  2. Path: sparky!uunet!spool.mu.edu!agate!stanford.edu!enterpoop.mit.edu!eff!ssd.intel.com!ichips!ichips!glew
  3. From: glew@pdx007.intel.com (Andy Glew)
  4. Subject: Re: branch-and-link
  5. In-Reply-To: dswartz@sw.stratus.com's message of 28 Dec 1992 04:49:40 GMT
  6. Message-ID: <GLEW.92Dec31163459@pdx007.intel.com>
  7. Sender: news@ichips.intel.com (News Account)
  8. Organization: Intel Corp., Hillsboro, Oregon
  9. References: <1hkqk3INNsns@transfer.stratus.com> <1hlll9INNe0s@uwm.edu>
  10.     <1hm0cpINN8nf@darkstar.UCSC.EDU> <1hm114INN6v2@transfer.stratus.com>
  11. Date: Fri, 1 Jan 1993 00:34:59 GMT
  12. Lines: 32
  13.  
  14.     On a related note (vis-a-vis debugging ease) to the branch-and-link issue, another peeve
  15.     I've always had is that no commercially available processors (that I know of) make NULL
  16.     pointer detection easy withou serious run-time overhead.  Various OS's try by unmapping
  17.     the first N pages of memory, which works fine until you run into a chip like the 68030,
  18.     which supports huge displacements.  Not to mention if the index register pushes the
  19.     effective address out of your protected window, you're hosed.  If you have a standard
  20.     base_reg+index_reg+disp format, it would seem to me that having the processor check the
  21.     base register for NULL and faulting if it is wouldn't be that hard (or inefficient).
  22.     Especially if NULL happens to be zero on that machine.
  23.  
  24. Rather contradicts another thread.
  25.  
  26. Compilers can perform significantly more optimizations if accesses
  27. to address 0 (and neighbourhood) are guaranteed not to fault.
  28.  
  29. See:
  30.  
  31.     "Proving safety of speculative load instructions at compile time"
  32.     David Bernstein
  33.     Michael Rodeh
  34.     Mooly Sagiv
  35.     IBM Israel
  36. --
  37.  
  38. Andy Glew, glew@ichips.intel.com
  39. Intel Corp., M/S JF1-19, 5200 NE Elam Young Pkwy, 
  40. Hillsboro, Oregon 97124-6497
  41.  
  42. This is a private posting; it does not indicate opinions or positions
  43. of Intel Corp.
  44.  
  45. Intel Inside (tm)
  46.