home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / arch / 12068 < prev    next >
Encoding:
Text File  |  1993-01-04  |  2.4 KB  |  70 lines
  1. Newsgroups: comp.arch
  2. Path: sparky!uunet!usc!sol.ctr.columbia.edu!eff!ssd.intel.com!ichips!ichips!glew
  3. From: glew@pdx007.intel.com (Andy Glew)
  4. Subject: Speculative Loads
  5. In-Reply-To: glew@pdx007.intel.com's message of Fri, 1 Jan 1993 00:34:59 GMT
  6. Message-ID: <GLEW.93Jan4095438@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.     <GLEW.92Dec31163459@pdx007.intel.com>
  12. Date: Mon, 4 Jan 1993 17:54:38 GMT
  13. Lines: 55
  14.  
  15.       On a related note (vis-a-vis debugging ease) to the branch-and-link issue, another peeve
  16.       I've always had is that no commercially available processors (that I know of) make NULL
  17.       pointer detection easy withou serious run-time overhead.  Various OS's try by unmapping
  18.       the first N pages of memory, which works fine until you run into a chip like the 68030,
  19.       which supports huge displacements.  Not to mention if the index register pushes the
  20.       effective address out of your protected window, you're hosed.  If you have a standard
  21.       base_reg+index_reg+disp format, it would seem to me that having the processor check the
  22.       base register for NULL and faulting if it is wouldn't be that hard (or inefficient).
  23.       Especially if NULL happens to be zero on that machine.
  24.  
  25.       Rather contradicts another thread.
  26.  
  27.       Compilers can perform significantly more optimizations if accesses
  28.       to address 0 (and neighbourhood) are guaranteed not to fault.
  29.  
  30.       See:
  31.  
  32.       "Proving safety of speculative load instructions at compile time"
  33.       David Bernstein
  34.       Michael Rodeh
  35.       Mooly Sagiv
  36.       IBM Israel
  37.  
  38.  
  39. Oops, forgot journal:
  40.  
  41. ConferencePaper {
  42.     Title = "Proving safety of speculative load instructions at compile time"
  43.     Author = "David Bernstein"
  44.     Author = "Michael Rodeh"
  45.     Author = "Mooly Sagiv"
  46.     Affiliation="IBM Israel"
  47.  
  48.     Book="Lecture Notes in Computer Science 582"
  49.     Editor="B. Krieg-Bruckner (ed.)"
  50.     
  51.     Conference="ESOP 92,
  52.         4th European Symposium on Programming"
  53.  
  54.     Place="Rennes, France"
  55.     Date=" Feb 92"
  56.  
  57.     Publisher="Springer-Verlag"
  58. }
  59.  
  60. --
  61.  
  62. Andy Glew, glew@ichips.intel.com
  63. Intel Corp., M/S JF1-19, 5200 NE Elam Young Pkwy, 
  64. Hillsboro, Oregon 97124-6497
  65.  
  66. This is a private posting; it does not indicate opinions or positions
  67. of Intel Corp.
  68.  
  69. Intel Inside (tm)
  70.