Eus wrote: > Hi Ho! > > On Fri, 2009-03-06 at 15:29 +0100, Paolo Bonzini wrote: >>> So while trapping variants can certainly be introduced it looks like >>> this task may be more difficult. >> I don't think you need to introduce trapping tree codes. You can >> introduce them directly in the front-end as >> >> s = x +nv y >> (((s ^ x) & (s ^ y)) < 0) ? trap () : s > > Could you please kindly explain a bit about it? > > Suppose s, x, and y are 8-bit signed integer. > If x and y are -128, s = (-128) + (-128), which will overflow. > Now if suppose s is 0, ((0 ^ -128) & (0 ^ -128)) == -128, which is less > than zero and will trap. This is correct. > But, if s is -128, ((-128 ^ -128) & (-128 ^ -128)) is zero and will not > trap. This is incorrect, isn't this?
Don't look at it as an arithmetic test, "< 0" is just a shortcut for "the most significant bit of the first operand is 1". So the formula's outcome only depends on the ANDs and XORs of the sign bits; it means, "trap if the result's sign is different from both addends' signs" or equivalently "check that the result's sign matches at least one addend's sign". You can also say "((s ^ x) & ~(x ^ y)) < 0", or equivalently "((s ^ y) & ~(x ^ y)) < 0". These mean "trap if the two addends have the same sign and the sum has a different sign". It is easy to prove that they are equivalent: s x y s^x s^y ~(x^y) equal? 0 0 0 0 0 1 yes (0) 0 0 1 0 1 0 yes (0) 0 1 0 1 0 0 yes (0) 0 1 1 1 1 1 yes (1) 1 0 0 1 1 1 yes (1) 1 0 1 1 0 0 yes (0) 1 1 0 0 1 0 yes (0) 1 1 1 0 0 1 yes (0) Paolo
