(j3.2006) BEQ, BNE?

[Keith Bierman]

True, but the popcount and other idioms should take care of those use cases.

The mind still reels at the notion that anyone would build a new processor
with this "feature".

Keith Bierman
khbkhb at gmail.com
kbiermank AIM
303 997 2749


On Sun, Feb 3, 2013 at 3:38 PM, Van Snyder <van.snyder at jpl.nasa.gov> wrote:

> 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
>
>
> _______________________________________________
> J3 mailing list
> J3 at mailman.j3-fortran.org
> http://mailman.j3-fortran.org/mailman/listinfo/j3
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.j3-fortran.org/pipermail/j3/attachments/20130203/763e75cb/attachment-0001.html