Hi Antonio,

On Wed, Mar 29, 2006 at 11:12:03PM +0200, Antonio Cuni wrote:
> The first doubt is about overflow-checked operations: I've noticed there 
> are a number of checked operations that can never fail due to their 
> semantic, such as "int_lt_ovf" or "int_rshift_ovf": am I missing 
> something or are they simply redundant?

They are indeed redundant.  We should check if anything can actually
generate them, and why.  My guess is that nothing does, in which case
they can be removed from the table in rpython.lltypesystem.lloperation
as well as from the LLInterpreter (they have to be removed from both
places, otherwise test_lloperation complains).

We also need to kill one of float_mod or float_fmod.  Right now they are
very C-ish: float_mod is like '%' in C, and float_fmod is like the C
stdlib fmod() function.  The difference has to do with negative
arguments.

> Moreover, I've found that the rtyper produces both "int_lshift_ovf" and 
> "int_lshift_ovf_val": what's the difference between the two? And what's 
> the semantic of "int_floordiv_ovf_zer" and "int_mod_ovf_zer"?

The three-letter prefix tell which exceptions are supposed to be checked
for:

    ('ovf', OverflowError),
    ('zer', ZeroDivisionError),
    ('val', ValueError),

So "int_lshift_ovf_val" should check if the second argument is negative
and raise ValueError if it is, as in regular Python.  Similarily,
"int_floordiv" is allowed to crash if the second argument is zero, but
"int_floordiv_zer" should check and raise ZeroDivisionError.

> The second question regards "uint_neg" and "uint_abs": considering the 
> an unsigned integer can't be negative, what are they intended to do? Are 
> they simply no-op?

Neither should be generated, as far as I remember, and they should be
taken out of the table too.  This said, "uint_abs" is clearly a no-op
but "uint_neg" -- if used -- stands for "negate the number and clamp it
back to the range of an unsigned word", which is the same as doing
"~x + 1".


A bientot,

Armin
_______________________________________________
pypy-dev@codespeak.net
http://codespeak.net/mailman/listinfo/pypy-dev

Reply via email to