Path: utzoo!attcan!uunet!lll-winken!lll-tis!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: <3622@s.cc.purdue.edu>
Date: 1 Nov 88 14:49:38 GMT
References: <1196@helios.ee.lbl.gov> <3616@s.cc.purdue.edu> <7523@ut-emx.UUCP>
Reply-To: ags@s.cc.purdue.edu.UUCP (Dave Seaman)
Organization: Purdue University
Lines: 32

In article <7523@ut-emx.UUCP> cccm001@ut-emx.UUCP (Tom Linsley) writes:
>
>Some further trivia relating to the CDC two-branch IF and 6600 logic:
>
>The values .TRUE. and .FALSE., when assigned to a variable, are represented
>as a (60-bit) word with all bits set (-0) and all bits clear (+0), respectively.
>
>Later CDC compilers (FTN, MNF) checked the sign bit (2**59), and .TRUE. was
>high, .FALSE. low.

I agree that there was more than one convention, but I believe most of the
later compilers used -1 (59 one bits out of 60 on a ones-complement
machine) for .TRUE. and zero for .FALSE.  I used to know exactly what each
of our dozen-or-so Fortran compilers did on the old CDC machines, but I
have forgotten most of the details.

>The venerable RUN compiler used a different convention, whereby a word with no
>bits set (+0) was .FALSE., and _any_other_value_ was .TRUE.  This convention
>made possible some peculiarly illogical logical behaviors, in that both "X" and
>".NOT. X" could be true simultaneously, if "X" had been given some nonzero (or
>"non-logical") value (i.e., neither +0 nor -0).  Remember that this compiler
>dates from a time when "strong typing" meant pounding hard on the keypunch.

I remember that there was some strangeness about logicals with the RUN
compiler, and this may have been it, but I think the later compilers used a
slightly different test:  zero for .FALSE. and nonzero for .TRUE.  The
ones-complement value -0 (all bits set) is considered "zero" as far as this
hardware test is concerned, so that the problem you described does not
arise.  This is also why .TRUE. was represented as not-quite-all-ones.

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