Path: utzoo!utgpu!watmath!clyde!att!pacbell!ames!amdahl!pyramid!prls!mips!earl@wright.mips.com From: earl@wright.mips.com (Earl Killian) Newsgroups: comp.arch Subject: condition codes vs. compare/branch Message-ID: <9198@wright.mips.COM> Date: 3 Dec 88 09:01:13 GMT References: <3386@pt.cs.cmu.edu> <74435@sun.uucp> <70@armada.UUCP> <550@m3.mfci.UUCP> <2152@ficc.uu.net> <552@m3.mfci.UUCP> <76500@sun.uucp> <10643@tekecs.TEK.COM> <8523@wright.mips.COM> <78977@sun.uucp> <8768@wright.mips.COM> <366@stca77.stc.oz> Sender: earl@mips.COM Organization: MIPS Computer Systems, Sunnyvale CA Lines: 75 In-reply-to: peter@stca77.stc.oz (Peter Jeremy) In article <366@stca77.stc.oz>, peter@stca77 (Peter Jeremy) writes: >In article <8768@wright.mips.COM> earl@wright.mips.com (Earl Killian) writes: >> A < B, A <= B, >>A > B, A >= B (for B != 0) are not as common as you might first guess >>(look up Stanford's published results). For example these are used at >>the tops of loops, but they're not useful at the bottom (if you >>implement loopback with <=, then your loops will fail when the >>termination value is 2**31-1). > >Only if you are using signed 32-bit arithmetic. You need a whole new set of >branch instructions for unsigned arithmetic as well. Getting a loop to >execute 2**n times, where n is wordsize, is a messy process, likely to >result in infinite loops if one is not careful. Unsigned branches won't fix the problem because they do the wrong thing for negative-positive comparison and because you get the same problem at the end of the unsigned range. On the other hand, the solution is simple, not messy as you suggest. (Also it's iterating up to 2**n-1, not iterating 2**n times that's the real problem.) To compile a Pascal "for i := l to h do body" you generate the equivalent of i = l; temp = h; if (i < temp) { temp += 1; do { body; i += 1; } while (i != temp); } which is very efficient, and the only conditional required in the loop is !=. >Stating that an instruction is not useful, because it does not have the >effect that the programmer wanted when used at the extremities of the >number range, is a bit specious. If you write compilers with an attitude like that you won't pass many validation suites. The pascal validation suite explicitly tests for iteration up to maxint, for example, because some compilers are sloppy. >> At loop bottom != is the appropriate >>test. (Also a global optimizer can convert A < B tests to A != B >>tests in some cases.) > >I prefer using relational operators rather than equality operators as >part of my "defensive coding" style. If A accidently gets munged due >to a bug, I prefer the loop to exit, rather than wait another 2**32 >(or whatever) iterations until A==B again. If I found that my compiler >was "optimising" relational tests to equality tests, I would report it >as a bug and scream until it was fixed - unless the compiler is going to >guarantee that my code has no bugs that might corrupt A or B. That's what "optimize" means; if you can't prove it executes the same as the original, you don't do it. For example, it is perfectly acceptable for the compiler to take for (i = 0; i < 10; i += 1) { <> } and compile it as if you wrote i = 0; if (i < 10) { do { <> i += 1; } while (i != 11); } and you won't scream because you'll never notice, because they execute identically. -- UUCP: {ames,decwrl,prls,pyramid}!mips!earl USPS: MIPS Computer Systems, 930 Arques Ave, Sunnyvale CA, 94086