Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!sdd.hp.com!elroy.jpl.nasa.gov!ames!sun-barr!newstop!sun!amdcad!mozart.amd.com!proton!tim
From: tim@proton.amd.com (Tim Olson)
Newsgroups: comp.std.c
Subject: Re: Questions about NCEG
Message-ID: <1990Jun5.212632.21625@mozart.amd.com>
Date: 5 Jun 90 21:26:32 GMT
References: <8846@celit.fps.com> <13038@smoke.BRL.MIL> <8924@celit.fps.com> <1990Jun5.024808.14003@twinsun.com> <8949@celit.fps.com>
Sender: usenet@mozart.amd.com (Usenet News)
Reply-To: tim@amd.com (Tim Olson)
Organization: Advanced Micro Devices, Inc., Austin, Texas
Lines: 27

In article <8949@celit.fps.com> ps@fps.com (Patricia Shanahan) writes:
| Incidentally, just as a matter of curiosity, if any of you have a copy of
| IEEE 754 handy, which does it say? Treat unordered comparisons as traps, 
| unless a special operator is used to handle them, or treat all unordered 
| relations as false.

The standard says that the result of a comparison shall be delivered
in one of two ways -- either as a condition code identifying one of:

	less than
	equal to
	greater than
	unordered

or as a true-false response to a comparison predicate.  In the later
case, if one or both of the operands is unordered, then the predicate
returns the value defined in the spec (mostly "false", but not-equal
(!=) would return "true"), and most predicates also signal an invalid
operand exception.

Whether this exception causes a trap or simply sets a "sticky" status
bit depends upon whether traps have been enabled or not for the
invalid operand exception.

	-- Tim Olson
	Advanced Micro Devices
	(tim@amd.com)