Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!lll-lcc!pyramid!prls!mips!mash From: mash@mips.UUCP (John Mashey) Newsgroups: comp.arch Subject: Re: AM29000 Booleans [numbers; long] Message-ID: <376@winchester.UUCP> Date: Thu, 7-May-87 15:36:36 EDT Article-I.D.: winchest.376 Posted: Thu May 7 15:36:36 1987 Date-Received: Sat, 9-May-87 09:39:10 EDT References: <1270@aw.sei.cmu.edu> <16560@amdcad.AMD.COM> <369@winchester.UUCP> <16588@amdcad.AMD.COM> Reply-To: mash@winchester.UUCP (John Mashey) Organization: MIPS Computer Systems, Sunnyvale, CA Lines: 35 In article <16588@amdcad.AMD.COM> bcase@amdcad.UUCP (Brian Case) writes: >In article <369@winchester.UUCP> mash@winchester.UUCP (John Mashey) writes: >>This is clearly correct [i.e., optimize for more frequent case], >>although I suspect compiler writers may moan a little. (No big deal: compiler writers would prefer that 0/1 be generated; this is not a major complaint.) >>However, it does raise an interesting question: was it not possible >>with the 29K pipeline to offer the "other" fast branches.... > ...Brian explains that the 29K pipeline design was incompatible > with other fast branches, unless they were made double-delayed. >Well, with our four-stage pipeline, branches must be executed in the >decode stage in order to avoid having double-delayed branches (something >that we *very* much want to avoid since at least some of our customers >will be doing some non-trivial assembly coding..... Even more important, the statistics (from Stanford) show that it's very hard to fill the 2nd delay slot, much harder than the first. >Does the MIPS processor have double-delayed branches? That would >explain why that processor can get away with these things. No, we found a way to do those branches with just one delay cycle. As noted, double-delays can hurt a lot. It took a lot of work, and the timing is very tight, but the statistics claimed it was a win. All of this is very dependent on pipeline design, so it may or may not be the right tradeoff for different architectures. We thought it was real important, so we made the design go that way. -- -john mashey DISCLAIMER: UUCP: {decvax,ucbvax,ihnp4}!decwrl!mips!mash, DDD: 408-720-1700, x253 USPS: MIPS Computer Systems, 930 E. Arques, Sunnyvale, CA 94086