home *** CD-ROM | disk | FTP | other *** search
- Path: sparky!uunet!zaphod.mps.ohio-state.edu!rpi!usenet.coe.montana.edu!ogicse!das-news.harvard.edu!cantaloupe.srv.cs.cmu.edu!lindsay
- From: lindsay+@cs.cmu.edu (Donald Lindsay)
- Newsgroups: comp.arch
- Subject: Re: trapping speculative ops
- Message-ID: <BtEzrK.Jso.2@cs.cmu.edu>
- Date: 23 Aug 92 02:18:55 GMT
- Article-I.D.: cs.BtEzrK.Jso.2
- References: <l8gi9jINNaad@exodus.Eng.Sun.COM> <1992Aug12.155317.27437@bcars64a.bnr.ca> <l8j0qkINNikb@exodus.Eng.Sun.COM>
- Sender: news@cs.cmu.edu (Usenet News System)
- Organization: School of Computer Science, Carnegie Mellon
- Lines: 35
- Nntp-Posting-Host: gandalf.cs.cmu.edu
-
-
- chased@rbbb.Eng.Sun.COM (David Chase) writes:
- >...being able to read zeros from page zero.
- >This lets you do a slightly better job of pipelining loops
- >of the form
- >
- > while (p != 0 && p -> data != K) p = p -> next;
-
- >>Don't you want the user code to trap?
- >No, not if it makes the code run significantly slower.
-
- I agree that an invalid zero page stops you from pulling this
- specific optimization. However, the invalid page trick has several
- virtues: it has no impact on hardware cost or speed, and it can
- detect bugs _after_ debugging is thought to be over.
-
- 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
-