(j3.2006) BEQ, BNE?

[Bill Long]

On 1/30/13 7:53 PM, Malcolm Cohen wrote:
>> I assume this is a theoretical question
>
> Sorry, but I am with Van here.
>
> It is so far from inconceivable that machines will have this kind of arithmetic
> that there are machines currently being produced with this kind of arithmetic.
>
> We have gone to great lengths in the real, integer, and bit models in clause 13
> to avoid gratuitous machine dependencies, even to the extent of handling radices
> other than 2.

Parts of those lengths are in 13.3 where we make the interpretation of 
negative integers as bit sequences processor dependent, as well as 
pretty much everything related to bit sequences for non-binary integer 
representations.

(Of course, I would have preferred to just have left BITS in the draft 
standard, avoiding the need for any of the B** functions.  But that 
position did not get consensus.)

>
> The assertion that Fortran should ignore everything other than twos complement
> integer arithmetic goes directly against our prime directive: "to promote
> portability ... on a variety of computing systems".

The issue is not two's complement.  It is whether any integer 
implementation has more than one internal representation for the same 
numerical value.  That is the only case where there is a difference 
between BEQ and integer comparison using ==. Such a representation was 
tried decades ago and hardware designers (hopefully) have learned that 
it was a mistake that should never be repeated.

Ultimately, it is a question of where we put our efforts.  We can go to 
lengths to accommodate extinct (for good reason) hardware failures, or 
focus on challenges that we can be confident will be affecting 
scientific computing in the time scale of vendor implementations of the 
next standard.  Among those challenges, I don't see duplicate 
representation of integer values anywhere on the horizon.

Cheers,
Bill



>
> Unless there is a good technical reason why a machine with arithmetic that is
> not twos complement should be considered unsuitable for Fortran, and I hear no
> such reason, excluding it could also fall foul of other guidelines J3 is
> reminded every meeting of its duty to adhere to...
>
> On the technical merits, it might be argued that the relational operation of
> bitwise equality would be so infrequently used that it is not justfied to
> include BEQ/BNE, but I am not hearing that argument either...
>
> Cheers,
>

-- 
Bill Long                                           longb at cray.com
Fortran Technical Support    &                 voice: 651-605-9024
Bioinformatics Software Development            fax:   651-605-9142
Cray Inc./Cray Plaza, Suite 210/380 Jackson St./St. Paul, MN 55101