Antonio Cuni wrote:

Finally, the last question is ootypesystem-specific: I've noticed that the rtyper sets the 'meta' field of every instance just after it has been created: what does it contain? It seems to me that it contains the class the object belongs to: am I correct? If so I could safely ignore that operations, because the CLI automatically tracks the type of each object, couldn't I?

this meta field can contain instances that have further fields beyond class_. class_ contains something of type ootype.Class, what is expected to be the runtime representation of a class in the backend type system, The extra fields are used to implement dynamically looked up class attributes, unless the CLI has direct support for such things, which are _not_ static class attributes, the simplest thing is to follow what the rtyper is asking for. It is true that in the future we may have the rtyper introduce the meta field only as stricly necessary.

Just a curiosity: why the name 'meta' instead of 'class' or 'type'?

to avoid simply thinking that is the type/class in Java/JVM etc sense. This is more similar to smalltalk metaclass.

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