[pypy-dev] Integer arithmetic
Armin Rigo
arigo at tunes.org
Sat Apr 9 22:34:30 CEST 2005
Hi,
A clarification of some points on IRC between Christian and Samuele:
The most important goal of the arithmetic changes discussed in the previous
e-mail was to have the same behavior before and after translation. That's why
the current r_int is dangerous: it propagates everywhere if you are not
careful. So up to yesterday, before translation you got overflow checking
everywhere where r_int goes, whereas after translation you only got overflow
checking if there is an explicit try: except OverflowError. The ovfchecked()
replacement of r_int fixes that problem by behaving the same before and after
translation.
r_uint, on the other hand, only means "unsigned wrap-around arithmetic", and
behaves consistently like this before and after translation.
So starting from now all integers behave in this wrap-around way, unless we
use explicit ovfchecked(); even plain signed integers. But because they
become longs when running on top of Python, at places we need to make sure
that we clamp them back to their least 32- (or 64-) bits. That's the purpose
of intmask(), which will convert a long back to an int by masking off the
extra bits (even turning a positive long into a negative int if needed).
intmask() is a no-op after translation.
Armin
More information about the Pypy-dev
mailing list