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