[prev in list] [next in list] [prev in thread] [next in thread] 

List:       pypy-dev
Subject:    Re: [pypy-dev] RPython rendering of % operator
From:       Carl Friedrich Bolz <cfbolz () gmx ! de>
Date:       2009-03-26 8:51:39
Message-ID: 49CB421B.4050600 () gmx ! de
[Download RAW message or body]

Amaury Forgeot d'Arc wrote:
> Hello,
> 
> On Thu, Mar 26, 2009 at 01:41, Ben Mellor <cumber@netspace.net.au> wrote:
>> Does anyone know why
>>
>> lambda x, y: x % y
>>
>> is being converted to a flow graph as:
>>
>> v2 = int_mod(x_0, y_0)
>> v1 = int_add(v2, [int_mul([int_and([cast_bool_to_int([int_le([int_xor(x_0,
>> y_0)], (0))])], [cast_bool_to_int([int_ne(v2, (0))])])], y_0)])
>>
>> (v1 is returned)
>>
>>
>> What's wrong with just v1 = int_mod(x_0, y_0)?
> 
> You are looking at the graph of the function:
>     pypy.rpython.lltypesystem.opimpl.op_int_mod
> 
> The difference is certainly because C and python handle modulus
> differently when one argument is negative:
> (-5 % 3) returns -2 in C, but 1 with python.
> 
> Now, I don't know whether RPython should absolutely implement python
> semantics here.
> RPython does not check for overflow for example.

The semantics of % in RPython _are_ the same as in Python. It's just
that the semantics of int_mod aren't that of Python, therefore % must be
mapped to something more complex. The reason why int_mod has the C
semantics is that it makes the life of all backends easier.

Cheers,

Carl Friedrich

_______________________________________________
pypy-dev@codespeak.net
http://codespeak.net/mailman/listinfo/pypy-dev
[prev in list] [next in list] [prev in thread] [next in thread]