Path: utzoo!attcan!uunet!lll-winken!lll-tis!helios.ee.lbl.gov!pasteur!ames!mailrus!purdue!i.cc.purdue.edu!h.cc.purdue.edu!s.cc.purdue.edu!ags
From: ags@s.cc.purdue.edu (Dave Seaman)
Newsgroups: comp.lang.fortran
Subject: Re: CDC FORTRAN trivia questions
Keywords: arithmetic if logical
Message-ID: <3627@s.cc.purdue.edu>
Date: 2 Nov 88 20:49:43 GMT
References: <1196@helios.ee.lbl.gov> <3616@s.cc.purdue.edu> <7523@ut-emx.UUCP> <3622@s.cc.purdue.edu> <7693@boring.cwi.nl>
Reply-To: ags@s.cc.purdue.edu.UUCP (Dave Seaman)
Organization: Purdue University
Lines: 38

>In article <7523@ut-emx.UUCP> cccm001@ut-emx.UUCP (Tom Linsley) writes:
>>The venerable RUN compiler used a different convention, whereby a word with no
>>bits set (+0) was .FALSE., and _any_other_value_ was .TRUE.  

In article <7693@boring.cwi.nl> dik@cwi.nl (Dik T. Winter) writes:
>I doubt this.  On the Cybers it is very difficult to distinguish +0 from the
>rest.  The hardware compare for zero gets both +0 and -0.  

The RUN compiler did indeed use this scheme.  It is true that the hardware
compare for zero gets both +0 and -0, but all this proves is that the RUN
compiler did not use the hardware compare for zero when testing logicals.

>(Testing L you have
>to write: OR(NOT(L)+0,L).GE.0 to distinguish +0).
>So I do not think any compiler has used this scheme.  

No, you just write .NOT. L, assuming L is typed LOGICAL.  The compiler does
the rest.

>The illogical thing is of course
>that you could have tests like (I.LT.0.AND.I.EQ.0) return .TRUE. or
>(P.GE.Q.OR.Q.GE.P) return .FALSE..

I don't see how.  I tried evaluating your first expression with I equal to
minus zero, and it still gave me .FALSE.  I tried the second expression
with P and Q both equal to minus zero, and it gave me .TRUE.  Did you have
some other values in mind?  It seems to me you are making unwarranted
assumptions about how compilers generate code.

 [Concerning my claim that the later compilers use nonzero for TRUE and
 zero for FALSE]:
>No, both FTN4 and FTN5 use negative for TRUE and positive for FALSE.  

You're right.  I got the compilers confused on this point.  It was the RUN
compiler that behaved as I described. 

-- 
Dave Seaman	  					
ags@j.cc.purdue.edu