[Historical] "Logical" type representation
Patrick F. McGehearty
The Fortran Logical datatype has multiple ways it could be implemented.
Most programs are not affected by the differing implementations, but some
older 'dusty decks' do integer arithmetic on interesting values and then use
the integers as logicials. These programs contain implicit assumptions
about how logicials are represented and are likely to have portability
problems. I would like to collect data on which machine/compilers use which
representations to help identify portability issues.
The most common practice that I'm aware of is to treat zero as false and
everything else as true. That is consistent with most C implementations that
I've heard of, and is the default for current HP Fortran compilers.
Another method is to treat odd numbers as true and even numbers as false.
This method means that only the low bit is tested for the true/false
condition, and may have been particularly efficient on some older
architectures.
A third method is to treat negative numbers at true and zero or positive
numbers as false. This method means that only the sign bit is tested for
the true/false condition. It was used by the Apollo Fortran compiler.
For those Fortran historians out there, do you know of which of these
methods were used on various popular machine/compilers? Have other
methods been used?
I'll post a summary when I get enough responses to make it worthwhile.
- Patrick McGehearty
pat...@rsn.hp.com
Craig T. Dedo
"Patrick F. McGehearty" wrote:
> The Fortran Logical datatype has multiple ways it could be implemented.
> Most programs are not affected by the differing implementations, but some
> older 'dusty decks' do integer arithmetic on interesting values and then use
> the integers as logicials. These programs contain implicit assumptions
> about how logicials are represented and are likely to have portability
> problems. I would like to collect data on which machine/compilers use which
> representations to help identify portability issues.
>
> The most common practice that I'm aware of is to treat zero as false and
> everything else as true. That is consistent with most C implementations that
> I've heard of, and is the default for current HP Fortran compilers.
I'm surprised that this method works at all, given the rules for the Fortran
LOGICAL data type. The reason is that the values .TRUE. and .FALSE. are LOGICAL
constants, which can be read in or written out just like numeric constants can
be. A Fortran compiler needs to write out the proper value regardless of the
number of intervening relational and logical operations, limited only by the
compiler's complexity limits.
> Another method is to treat odd numbers as true and even numbers as false.
> This method means that only the low bit is tested for the true/false
> condition, and may have been particularly efficient on some older
> architectures.
I have used the DEC compilers on OpemVMS and Windows NT. They use this
method. The contants .TRUE. and .FALSE. are 1 and 0, respectively. Relational
and logical oeprators produce either 1 or 0. The tests for logical equivalence
and non-equivalence test only the low-order bit.
> A third method is to treat negative numbers at true and zero or positive
> numbers as false. This method means that only the sign bit is tested for
> the true/false condition. It was used by the Apollo Fortran compiler.
>
> For those Fortran historians out there, do you know of which of these
> methods were used on various popular machine/compilers? Have other
> methods been used?
>
> I'll post a summary when I get enough responses to make it worthwhile.
>
> - Patrick McGehearty
> pat...@rsn.hp.com
You may wish to do some experimentation on your own, using the various
compilers that are available and looking at the contents of LOGICAL variables
with the debugger.
--
----------
Sincerely,
Craig T. Dedo Internet: Craig...@execpc.com
Elmbrook Computer Services Voice Phone: (414) 783-5869
17130 W. Burleigh Place Fax Phone: (414) 783-5928
Brookfield, WI 53005 Disclaimer: These opinions are mine alone.
USA They do NOT represent any organization.
"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety." -- Benjamin Franklin (1759)
fair...@sldb4.slac.stanford.edu
"Craig T. Dedo" <Craig...@execpc.com> writes:
> "Patrick F. McGehearty" wrote:
[...]
>> Another method is to treat odd numbers as true and even numbers as false.
>> This method means that only the low bit is tested for the true/false
>> condition, and may have been particularly efficient on some older
>> architectures.
>
> I have used the DEC compilers on OpemVMS and Windows NT. They use this
> method. The contants .TRUE. and .FALSE. are 1 and 0, respectively.
Actually, on VMS .TRUE. is represented by -1, i.e., Z'FFFFFFFF'.
This is convenient when doing bit-wise logical operations on mixed
interger and logical variables and expressions since -1 is all bits
set. :-) I don;t know what the implementation is on WNT or DU.
-Ken
--
Kenneth H. Fairfield | Internet: Fair...@Slac.Stanford.Edu
SLAC, P.O.Box 4349, MS 46 | DECnet: 45537::FAIRFIELD (45537=SLACVX)
Stanford, CA 94309 | Voice: 650-926-2924 FAX: 650-926-3515
-------------------------------------------------------------------------
These opinions are mine, not SLAC's, Stanford's, nor the DOE's...
bg...@my-dejanews.com
> Actually, on VMS .TRUE. is represented by -1, i.e., Z'FFFFFFFF'.
> This is convenient when doing bit-wise logical operations on mixed
> interger and logical variables and expressions since -1 is all bits
> set. :-) I don;t know what the implementation is on WNT or DU.
And I'm trying to remember how the 60-bit CDC Fortrans of old
represented .TRUE. and .FALSE. I think it may have been
TRUE. = 00000000000000000000
FALSE. = 77777777777777777776
(both numbers in base 8, as usual for that platform)
but my memory is fuzzy on this since it isn't something I
ever really needed to know. It may have been the case that
FALSE. had all bits set (that's -0 rather than -1). Does
anyone here remember for sure?
The interesting point here is that even the assumption that 0 is .FALSE.
is potentially unsafe. Users of UNIX know this well: /bin/true is
equivalent to the C one-liner
int main(void) { return 0; }
Jeff Drummond
In article <87yahcd...@bglbv.my-dejanews.com>, <bg...@my-dejanews.com> writes:
|> fair...@sldb4.slac.stanford.edu writes:
|>
|> > Actually, on VMS .TRUE. is represented by -1, i.e., Z'FFFFFFFF'.
|> > This is convenient when doing bit-wise logical operations on mixed
|> > interger and logical variables and expressions since -1 is all bits
|> > set. :-) I don;t know what the implementation is on WNT or DU.
|>
|> And I'm trying to remember how the 60-bit CDC Fortrans of old
|> represented .TRUE. and .FALSE. I think it may have been
|> .FALSE. = 77777777777777777776
|> (both numbers in base 8, as usual for that platform)
|> but my memory is fuzzy on this since it isn't something I
|> ever really needed to know. It may have been the case that
|> anyone here remember for sure?
IIRC, .FALSE. was all ones (-0 in ones-complement) on the CDC 60-bit Fortran
implementations.
Early CRAY systems used positive/negative for .TRUE./.FALSE.; later ones
used the C-style nonzero/zero.
-Jeff j...@sgi.com
--
"Bad luck is universal. Don't take it personally." --Solomon Short
Toon Moene
Positive / negative zero only works if your jump / branch / skip on
condition can discriminate between them.
There was an (in)famous bug in the UNIVAC Fortran compiler in the early
eighties, where unreachable basic blocks were flagged with bit 0 as
opposed to one in an array of 36 bit words.
For speed, the first thing the code generator did was to test all double
words in the array for zero - to throw away 72 basic blocks at once if
they were unreachable.
Unfortunately, Double Skip on Zero skipped both on positive _and_
negative zero.
Question to the Fortran compiler bug list:
I have this 3000 line Fortran routine and after compilation, only a
<very small> object file results - how comes ?
:-)
--
Toon Moene (to...@moene.indiv.nluug.nl)
Saturnushof 14, 3738 XG Maartensdijk, The Netherlands
Phone: +31 346 214290; Fax: +31 346 214286
GNU Fortran: http://world.std.com/~burley/g77.html
Dr Ivan D Reid, muSR Facility
>Question to the Fortran compiler bug list:
>I have this 3000 line Fortran routine and after compilation, only a
><very small> object file results - how comes ?
You got a bit carried away with the depth of explanation in your
comment lines?
>:-)
;-)
--
Ivan Reid, Paul Scherrer Institute, CH. http://musr0.psi.ch/ re...@psi.ch
MuSR99 Conference, Les Diablerets: http://www1.psi.ch/~musr99/musr99.html
KotPT -- "for stupidity above and beyond the call of duty".
Roger Caffin
>Question to the Fortran compiler bug list:
>
>I have this 3000 line Fortran routine and after compilation, only a
><very small> object file results - how comes ?
Simple.
Since it is just a test program it doesn't really do anything.
You are using the DVF compiler with full optimisation turned on. This allows
the compiler to analyse your code and work out what you are doing, prior to
optimisation.
Since you are not really doing anything, the optimiser deleted most of the
compiled but worthless code.....
Cheers,
Roger Caffin
Berrilee Consulting Services P/L
Australia
bg...@my-deja.com
> Toon Moene wrote in message
[In the context of a ones' complement machine:]
> >Question to the Fortran compiler bug list:
> >
> >I have this 3000 line Fortran routine and after compilation, only a
> ><very small> object file results - how comes ?
> Simple.
> Since it is just a test program it doesn't really do anything.
> You are using the DVF compiler with full optimisation turned on.
[...]
You are being unfair to DVF. Toon was paraphrasing an actual report of
the compiler bug he described in the rest of his post. Judging from
the description, this could not have occurred on any of the hardware
architectures supported by DVF.
You are also raising the broader question: should software attempt to
read the user's mind? My current answer to this is "certainly not:
such attempts are bound to fail on *my* mind, and I am prepared to
go to great lengths to make sure that this remains so for the
foreseeable future."
Dick Hendrickson
Are you sure about this? Compilers routinely discard "dead code"
and that's almost always a good thing. Many times a program is
written to deal with the general case and then specific cases are
compiled by changing a few constants in a parameter statement. A
good optimizer should do the right thing. (Yes, it's a good idea to
have a /non-optimize switch and a good compiler also warns about
non-reachable blocks of dead code).
I've got a program that is prepared to deal with Quad precision
so it defines parameters R1_KV, R2_KV, and R4_KV. And I have a few
IF statements like IF (R2_KV .EQ. R4_KV) blah blah
to do the right thing on processors that don't support Quad precision.
I'd expect the compiler to do the comparison at compile time and
not generate the dead code.
Similarly, compilers do interprocedural analysis (or inlining which
is about the same thing) and the compiled coded is based on the
actual values of the arguments. Many general purpose subroutines
are called from only a few places and have a few constants for
some of their arguments. The code can be much more efficient if
the actual values are used at compile time to control code
generation.
Dick Hendrickson
Roger Caffin
>> ><very small> object file results - how comes ?
>> Simple.
>> Since it is just a test program it doesn't really do anything.
>> You are using the DVF compiler with full optimisation turned on.
>the compiler bug he described in the rest of his post. Judging from
>the description, this could not have occurred on any of the hardware
>architectures supported by DVF.
Er: humour?
(btw: I have been using DEC Fortran since about 1972. My only bias is in
favour of it!)
>You are also raising the broader question: should software attempt to
>read the user's mind? My current answer to this is "certainly not:
>such attempts are bound to fail on *my* mind, and I am prepared to
>go to great lengths to make sure that this remains so for the
>foreseeable future."
Oh well. 2c.
My answer is "certainly yes", with the following assumptions made explicit.
1) the optimiser is able to guarantee that the results are still the same
afterwards.
2) the optimised code either is smaller or preferably runs faster.
Example:
Some heavy (in house) image analysis code, running on VAXen.
The Fortran Gem compiler was released on the new Alpha, so we thought we
would try it.
Compiled and ran on small Alpha workstation with either beta or 1.0 release
of compiler. It ran faster, but not that much faster. But nice enough.
Then we (ie Digit techie) turned on the optimiser and recompiled (with a
smile).
The code ran 5 times faster again. Yes, "five times".
What had happened? The optimiser had taken full advantage of what sense it
could make of my source code and had reshuffled the binary to fill up the
CPU pipeline as much a possible.
Did I like it? :-)
Cheers,
Roger Caffin