Front page | perl.perl5.porters |
Postings from February 2001
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