home *** CD-ROM | disk | FTP | other *** search
- Newsgroups: comp.arch
- Path: sparky!uunet!europa.asd.contel.com!darwin.sura.net!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!eff!iWarp.intel.com|ichips!ichips!glew
- From: glew@pdx007.intel.com (Andy Glew)
- Subject: Re: trapping speculative ops
- In-Reply-To: lindsay+@cs.cmu.edu's message of 23 Aug 92 02:18:55 GMT
- Message-ID: <GLEW.92Aug25180333@pdx007.intel.com>
- Sender: news@ichips.intel.com (News Account)
- Organization: Intel Corp., Hillsboro, Oregon
- References: <l8gi9jINNaad@exodus.Eng.Sun.COM> <1992Aug12.155317.27437@bcars64a.bnr.ca>
- <l8j0qkINNikb@exodus.Eng.Sun.COM> <BtEzrK.Jso.2@cs.cmu.edu>
- Date: Wed, 26 Aug 1992 02:03:33 GMT
- Lines: 37
-
-
- But this is just a specific optimization. The broader question is,
- waht about traps while executing speculatively? There seem to be two
- answers:
-
- 1) Let the hardware do all the speculative execution. This puts it on
- the hardware's head to not trap until it knows it really should have.
-
- 2) Allow compiled code a way to postpone consequences until it
- wants to know. This covers e.g.
-
- if( b != 0 ) c = a/b;
-
- and an assortment of other cases.
-
- The problem with (1) is that it makes for complex hardware. The
- problem with (2) is that instruction sets are generally not set
- up to allow such leeway.
- --
- Don D.C.Lindsay Carnegie Mellon Computer Science
-
-
- Wen-mei Hwu's IMPACT group at the University of Illinois has been
- publishing a sequence of papers exploring instruction set architecture
- support for 2).
-
-
- --
-
- Andy Glew, glew@ichips.intel.com
- Intel Corp., M/S JF1-19, 5200 NE Elam Young Pkwy,
- Hillsboro, Oregon 97124-6497
-
- This is a private posting; it does not indicate opinions or positions
- of Intel Corp.
-
- Intel Inside (tm)
-