On 20 Jun 2008, at 00:45, Krishna Nandivada Venkata wrote: > > > [EMAIL PROTECTED] wrote on 06/19/2008 09:31:51 > PM: >> >> So, here are some of our options: >> >> (a) Be unsignedness preserving in the broken K&R C way. >> (b) Be value preserving in the broken ANSI C way. >> (c) Be value preserving correctly (i.e., i32 < u32 == true). >> (d) Disallow signed vs. unsigned comparisons, forcing the programmer >> to explicitly convert. >> (e) Introduce different signed and unsigned operators (probably a bad >> idea) >> >> C#, BTW, does (c) for 32-bit values, but (d) for 64-bit values. >> >> Any opinions? >> > > I think we can guess the reasons behind that. When comparing two > numbers of > same size they could use a representation of the next size (say the > two > numbers are of sizes 2^x and 2^y, then copy them to a representation > of > size 2^z, where z=max(x, y)+1) and then compare. But such a scheme > won't be > possible when comparing two numbers of max size. So they might not use > scheme (c) in that case. In general, I think both (c) and (d) are > acceptable choices (but we have to be consistent). I would give (c) > the > higher preference. > > Warm regards, > Krishna.
Hi Krishna, I agree that value preserving is the right semantics regardless of width. This can be implemented for 32-bit numbers by widening to 64- bit. The best I can come up with for 64-bit numbers is the following for the Java target (representing unsigned longs as signed longs): s1, s2: long; u1, u2: ulong; [[ s1 < s2 ]] = s1 < s2 [[ s1 < u2 ]] = s1 < 0 || s1+Long.MIN_VALUE < u2+Long.MIN_VALUE [[ u1 < u2 ]] = u1+Long.MIN_VALUE < u2+Long.MIN_VALUE [[ u1 < s2 ]] = !(s2 < 0) && u1+Long.MIN_VALUE < s2+Long.MIN_VALUE In generated C++ code, we can avoid adding MIN_VALUE since C++ supports unsigned directly: [[ s1 < s2 ]] = s1 < s2 [[ s1 < u2 ]] = s1 < 0 || (unsigned long long) s1 < u2 [[ u1 < u2 ]] = u1 < u2 [[ u1 < s2 ]] = !(s2 < 0) && u1 < (unsigned long long) s2 I don't think the double compare will affect performance much. I suspect signed vs. unsigned comparisons will not be as common as in C+ +. The most common use case of ulong comparisons is probably bounds checks for ulong-indexed rails. In this case, the type system would require that the index and the bound both be ulongs. Nate ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php _______________________________________________ X10-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/x10-users
