develooper Front page | perl.perl5.porters | Postings from February 2001

Re: IV preservation (was Re: [PATCH 5.7.0] compiling on OS/2)

Thread Previous | Thread Next
From:
Ilya Zakharevich
Date:
February 16, 2001 13:00
Subject:
Re: IV preservation (was Re: [PATCH 5.7.0] compiling on OS/2)
Message ID:
20010216160057.E20979@math.ohio-state.edu
On Fri, Feb 16, 2001 at 06:47:07PM +0000, Nicholas Clark wrote:
> > > It wants to move *integer* operations from FPU to "software" (read integer
> > > hardware). All other operations remain in hardware.
> > 
> > All the logic to deside *which* branch it wants to take is in software.
> 
> The revised version for add and subtract now performs the operation as
> unsigned, and tracks the sign separately

This is exactly what I said: moving work from hardware to software.

> It is not trivial, but I would not consider it intricate or complicated.
> (in that each pp function is understandable in isolation, and the flow
> through each pp function is not convoluted)

"Understandable" and "does a kosher thing in the floating-point world"
rarely go along.  [This is a general remark, I did not see your code.
But I would be scared to do this - without *a lot* of FP-background.]

> The intent was to (and the implementation should)
> 
> 1: the first time the conversion was requested, cache the result of the
>    conversion, or the closest approximating integer,
>    and either way flag that the IV slot held a valid value;
>    "private" if the conversion was not accurate, "public" if it was.2: 

You cannot "just reuse" private flags for your purposes.  They are
used for other things (do not remember, tie()ing?).

> > My reading of sane numbers is that for most operations you know *in
> > advance* to which form it will convert its arguments.  The number of
> > opcodes which inspect the type of the operand, then behave accordingly
> > (here I mean ++, not & - no *drastic* changes in operation) is
> > minimal.  Being a few, you can memorize them, then *predict* what your
> > program is doing.
> > 
> > What Perl taught us is that DWIM is *not always* better than sliced
> > bread.  By a significant increase in the number of operations which
> > inspect their arguments, the patch makes prediction harder, not
> > easier.
> 
> I had not thought of this.
> Would it make sense to keep the 5.6 numeric operator code base, and
> allow a program to switch to them by means of a "use float'" pragma
> that works in much the same way as the current "use integer;" ?

Hmm, an interesting idea.

Ilya

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About