home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / comp / arch / 9270 < prev    next >
Encoding:
Text File  |  1992-09-08  |  2.6 KB  |  58 lines
  1. Newsgroups: comp.arch
  2. Path: sparky!uunet!email!mips.complang.tuwien.ac.at!anton
  3. From: anton@mips.complang.tuwien.ac.at (Anton Martin Ertl)
  4. Subject: Re: trapping speculative ops (LONG)
  5. Message-ID: <1992Sep8.091112.25367@email.tuwien.ac.at>
  6. Sender: news@email.tuwien.ac.at
  7. Nntp-Posting-Host: mips.complang.tuwien.ac.at
  8. Organization: Institut fuer Computersprachen, Technische Universitaet Wien
  9. References: <CLIFFC.92Aug28085924@antigone.rice.edu> <1992Aug31.224611.5196@odin.diku.dk>
  10. Date: Tue, 8 Sep 1992 09:11:12 GMT
  11. Lines: 45
  12.  
  13. Andi Krall have written a tech report on this problem. Our solution is
  14. slightly different from the one discussed here. The trap bit is
  15. checked explicitely (by a branch instruction). This seems to waste
  16. instruction bandwidth, but we assumed a high-degree superscalar
  17. processor, where the problem is not the number of instructions, but
  18. their low parallelism. This approach has the advantage that the
  19. compiler can move more than the roots of a dependence DAG above a
  20. branch.
  21.  
  22. @TechReport{ertl&krall92exceptions,
  23.   author =     "M. Anton Ertl and Andreas Krall",
  24.   title =     "Exception Handling vs.\ Speculative Execution",
  25.   institution =     "Institut f{\"u}r Computersprachen, Technische
  26.          Universit{\"a}t Wien",
  27.   year =     "1992",
  28.   type =     "Bericht",
  29.   number =     "TR 1851-1992-10",
  30.   abstract =    "Superscalar processors, which execute basic blocks
  31.          sequentially, cannot use much instruction level
  32.          parallelism. Speculative execution has been proposed
  33.          to execute basic blocks in parallel.  Previous
  34.          approaches for speculative execution rely heavily
  35.          either on hardware or on software. A pure hardware
  36.          approach is expensive. A pure software approach like
  37.          restricted percolation suffers from low performance,
  38.          because exception-generating instructions cannot be
  39.          executed speculatively.  General percolation solves
  40.          this problem by ignoring exceptions. This behaviour
  41.          is clearly unacceptable, as many applications rely on
  42.          the correct handling of exceptions.  We propose
  43.          delayed exceptions, a combination of hardware and
  44.          compiler extensions that can provide correct
  45.          exception handling in compiler-based speculative
  46.          execution.  Exception-generating instructions are
  47.          split into a trap-noting version that can be moved
  48.          around freely, and a trap-check that calls
  49.          compiler-generated fix-up code on an exception.
  50.          Delayed exceptions can also be used to solve the
  51.          imprecise exception problem."
  52. }
  53.  
  54. - anton
  55. -- 
  56. M. Anton Ertl                    Some things have to be seen to be believed
  57. anton@mips.complang.tuwien.ac.at Most things have to be believed to be seen
  58.