 |
 |
Date: Wed, 23 Mar 2005 17:39:06 -0700 From: James Giles <[log in to unmask]> Daniel and Nicola Grimwood wrote: ... > yes I was thinking in terms of 0 and 1. I agree with them not having an > ordering now that it's been pointed out. [...] Before C the most common "under the hood" implementation of logicals I came across was negative means .true. and positive means .false. That's because almost all hardware had a conditional branch based on the sign bit of an operand register. If memory serves, from my more direct debugging days, since the debugger had to understand an implementation's representation and usage patterns, Digital/Compaq Fortran on Alpha/Tru64 would store all-0s for .false. and store all-1s for .true.. Thus if you equivalanced 8 logical*1's with 1 logical*8 and set the logical*8 you would see the same value in each of the logical*1s. Non-standard; don't count on it. But there's another aspect: when *TESTING* a logical Alpha tested even for false and odd for true; it had instructions for conditional branch and conditional move based on the low bit. "Proper" C logicals (0/1 for false/true) would still work because of even/odd, not because of positive/negative, non-negative/negative or zero/non-zero, but C integers-used-as-logicals (zero/non-zero) may fail because 2 is consider true for C but false for the Fortran implementation I'm describing. In other words, there is the canonical value to use for a logical's value, and there is the testing method employed. The testing method must work for the canonical value, but depending on it to work for non-canonical values is surely a way to get into portability trouble. Each implementation surely has its reasons for choosing the canonical value and test method the way they did.