The problem is that you will lose performance if more integer types are implemented, just because of the added overhead of handling them. Since the time consumed in the arithmetic operations for native integers is so small compared to all the stuff that surrounds them (take a look at f_add in operators.c, for example), I'm certain that it's overall faster to instead use 64 bit integers all over with --with-long-long-int.
/ Martin Stjernholm, Roxen IS
Previous text:
2003-02-26 23:08: Subject: Re: 64 bit ints
On Wed, Feb 26, 2003 at 09:30:04PM +0100, Mirar @ Pike developers forum wrote:
0x80000000 is -2147483648 if you cram it inside a signed 2-complement (normal) 32 bit integer.
According to Pike, this is not the case:
int x; x = 0x80000000;
(1) Result: 2147483648
On one hand, I want to have flexibility (64 and more bit ints), on the other hand I don't want to lose performance (say, I've to make a lot of operations on IPv4 addresses).
Bignums are good enough (for my purposes), but I can't do something like:
Bignum a_bignum = 12345;
or:
a_bignum = an_int + another_int;
and expect this to work (there is no `=() in Pike, but that is another story).
Yes, I could compile Pike without autobignums, but... The above prevents me from doing this :)
/Al
/ Brevbäraren