Path: utzoo!mnetor!uunet!husc6!rutgers!iuvax!pur-ee!uiucdcs!uiucdcsb!kenny
From: kenny@uiucdcsb.cs.uiuc.edu
Newsgroups: comp.arch
Subject: Re: FORTRAN Horror
Message-ID: <165100015@uiucdcsb>
Date: 24 Mar 88 17:00:00 GMT
References: <1135@pembina.UUCP>
Lines: 35
Nf-ID: #R:pembina.UUCP:1135:uiucdcsb:165100015:000:1296
Nf-From: uiucdcsb.cs.uiuc.edu!kenny    Mar 24 11:00:00 1988


/* Written  2:41 am  Mar 23, 1988 by ok@quintus.UUCP in uiucdcsb:comp.arch */
What's wrong with
	typedef enum {LESS = -1, EQUAL = 0, GREATER = 1} Order;
	extern Order int_compare(int, int);

	switch (int_compare(fun(4,"test"), 22) {
	    case LESS:    ...; break;
	    case EQUAL:   ...; break;
	    case GREATER: ...; break;
	}
No new syntax needed.  Where something like this pays off is when
you are comparing strings or complicated records, and you don't
want to do it twice, but that is when you are defining your own
comparison function anyway.  This is really a comp.lang.misc issue.
/* End of text from uiucdcsb:comp.arch */

	That baroque syntax isn't needed anyway.  Any good optimizing
compiler with CSE elimination will pull the second test out of

	{
	  register int result;
	  if ((result = fun (4, "test")) < 22) {stuff}
	  else if (result == 22) {stuff}
	  else /* result > 22 */ {stuff}
	}

	But, (and here's the gotcha), it isn't a very big win.  One
compiler-writer of my acquaintance tried just that optimization,
remembering when the result of a comparison was already in the
condition codes, and threw the compiler at a collection of existing
application and benchmark programs.  The only one on which he could
measure any speedup at all was a `fat pivot' quicksort.

Kevin