(j3.2006) BEQ, BNE?

Van Snyder van.snyder
Sun Feb 3 17:38:16 EST 2013


On Sun, 2013-02-03 at 15:23 -0700, Keith Bierman wrote:
> Really? Surely on such a processor the ABS function would "normalize"
> to one or the other.

Right... which is exactly what you DO NOT want if you're trying to test
for (in)equality of bit strings!

> Keith Bierman
> khbkhb at gmail.com
> kbiermank AIM
> 303 997 2749
> 
> 
> On Sun, Feb 3, 2013 at 3:18 PM, Van Snyder <van.snyder at jpl.nasa.gov>
> wrote:
>         On Sun, 2013-02-03 at 05:58 -0700, Dan Nagle wrote:
>         > Hi,
>         >
>         > For integers, how difficult is it to understand the idiom
>         >
>         > abs( i) < 1
>         >
>         > or
>         >
>         > abs( i - j) < 1
>         
>         
>         There is no problem understanding this, except it doesn't work
>         for bits
>         if all zero bits and all one bits both represent numeric zero.
>         
>         >
>         > On Feb 3, 2013, at 05:12 , Robert Corbett
>         <robert.corbett at oracle.com> wrote:
>         >
>         > > On 02/01/13 12:07, Van Snyder wrote:
>         > >> On Fri, 2013-02-01 at 10:10 -0700, Keith Bierman wrote:
>         > >>> The no so obvious thing is what cot(s) that may impose
>         on the
>         > >>> implementors. Folks who were certain there were fixed
>         numbers of
>         > >>> intrinsics may have "hard" limits, the interactions with
>         optimization
>         > >>> and debuggers, etc. Different implementors could face
>         very different
>         > >>> costs (from what very little I recall of the NAG
>         compiler, once upon a
>         > >>> time I think it would have been small for Malcolm). For
>         some other
>         > >>> compilers, not so small (not huge, but the combination
>         of scarce
>         > >>> development, integration and test resources for most
>         compiler groups
>         > >>> should never be underestimated. The more highly
>         optimizing the
>         > >>> environment, the more likely it is that even trivial
>         changes will have
>         > >>> more considerable impact).
>         > >> Bob Corbett argued that if one has written
>         > >>
>         > >>   if ( popcnt(ieor(i,j)) == 0 )
>         > >> or
>         > >>   if ( BLE(i,j) .and. BLE(j,i) )
>         > >> or
>         > >>   if ( BGE(i,j) .and. BGE(j,i) )
>         > >> or
>         > >>   any of the dozen or so other ways to say the same
>         thing,
>         > >>
>         > >> a competent optimizing compiler will have optimized "the
>         idioms" to an
>         > >> unsigned test for equality.
>         > >>
>         > >> How is that "easier" than implementing BEQ and BNE?
>         > >
>         > > It does not require changing the compiler front-end other
>         than at the final step
>         > > when the next lower level of intermediate code is
>         produced.  Adding a new
>         > > intrinsic function to Oracle Solaris Studio Fortran
>         requires extending the
>         > > front-end intermediate code, adding new entries to the
>         intrinsic function
>         > > table,  adding new code for semantic checking, extending
>         the module file format,
>         > > updating the module file reader and writer, and updating
>         the constant folding
>         > > routines.  I might well have missed some steps.
>         > >
>         > > Bob Corbett
>         > > _______________________________________________
>         > > J3 mailing list
>         > > J3 at mailman.j3-fortran.org
>         > > http://mailman.j3-fortran.org/mailman/listinfo/j3
>         >
>         
>         
>         _______________________________________________
>         J3 mailing list
>         J3 at mailman.j3-fortran.org
>         http://mailman.j3-fortran.org/mailman/listinfo/j3
>         
> 
> 
> _______________________________________________
> J3 mailing list
> J3 at mailman.j3-fortran.org
> http://mailman.j3-fortran.org/mailman/listinfo/j3





More information about the J3 mailing list