Hi Eric, On Thu, May 26, 2005 at 11:57:57AM +0200, ericvrp@codespeak.net wrote:

pypy/dist/pypy/rpython/rint.py Log: added more rint methods. Someone please check if this is basicly right!

Yes, great work (if boringly repetitive :-) The policy about signed versus unsigned operations is not very clearly defined for the moment. Some operations give a different result when interpreting their arguments as signed or unsigned, while others don't. A few details about it:

+ def rtype_lshift((s_int1, s_int2)): + if s_int1.unsigned or s_int2.unsigned:

According to annotation/binaryop.py, lshift and rshift are signed/unsigned depending on the first argument only, not on the shift count.

+ def rtype_pow((s_int1, s_int2)): + #XXX RPythonTyper gives this error: TypeError: rtype_pow() takes exactly 1 argument (2 given)

'pow' is the equivalent of the built-in pow(), which can take a third argument. Our pow operation always takes three arguments. But at this point rtype_pow should probably only generate a two-arguments int_pow or uint_pow, optionally followed by a second operation, int_mod or uint_mod, depending on if the 3rd arg is a SomeInteger or a None: def rtype_pow((s_int1, s_int2), s_int3): ... v_result = direct_op(...) if isinstance(s_int3, SomeInteger): v_int3 = receive(...) v_result = direct_op(..., [v_result, v_int3], ...) elif s_int3.is_constant() and s_int3.const is None: pass else: raise TyperError("pow() 3rd argument must be int or None") return v_result

+ def rtype_eq((s_int1, s_int2)):

Should probably use the same logic as rtype_l & friends, to avoid considering a signed negative number as possibly equal to a large unsigned number.

+ #Unary arithmetic operations

Same signed/unsigned distinctions needed... For abs of an unsigned number, and for pos:

+ def rtype_pos(s_int): + #XXX I think this is a nop and should really be removed from the graph

you can just return the received v_int variable directly, without any direct_op(). A bientot, Armin