Front page | perl.perl5.porters |
Postings from November 2000
On Thu, Oct 05, 2000 at 08:26:00AM -0500, Jarkko Hietaniemi wrote: > On Thu, Oct 05, 2000 at 02:19:40PM +0100, Nicholas Clark wrote: > > On Thu, Oct 05, 2000 at 06:38:59AM -0500, Jarkko Hietaniemi wrote: > > > I have been down this path many times and I think I once even hacked > > > pp_add and pp_substract to correctly detect overflow situations and > > > returns IVs/UVs when possible. The problem is that this slowed down > > > Perl by about 10%. > > > > even for a lazier test such as (for 32 bit ints) both bits 30 being clear > > for addition means that there can't be overflow? > > and both arguments < 2^16 for multiplication? > > You can try be smarter but I think in any case you will end up with > a couple of tests before you do the actual op, so some speed hit is > inevitable. And remember that 32 bit ints is awfully quaint :-) The > basic source suckage here is C: however nice portable assembler it is, > it's too high-level because you can't detect whether you just had an > integer overflow. I think I've convinced myself that for c = a + b if b > 0 you have overflow if c < a if b < 0 you have overflow if c > a (if b == 0 you can't get overflow) and for c = a - b if b > 0 you have overflow if c > a if b < 0 you have overflow if c < a (if b == 0 you can't get overflow) where a, b and c are all signed or all unsigned, for any length integer. and that the above works even when 0 - INT_MIN == INT_MIN as it doesn't attempt unary negation of anything. Was this what you benchmarked, or did you do bit shuffling? (or what is wrong with my thinking?) Nicholas ClarkThread Previous | Thread Next