Timon Gehr wrote: > On 07/06/2011 00:20, Timon Gehr wrote: > <snip> >> I'd much prefer the behavior to be defined as 1<<x; being equivalent to >> 1<<(0x1f&x); (That's what D effectively does during runtime. It is also what >> the machine code supports, at least in x87). > > Defining the behaviour to match that of one brand of processor would be arbitrary and > confusing.
Well, not too much. It is the easiest behavior to implement in hardware. I thought that it is the most common behavior on different brands of processors, but I might be mistaken. Is there any processor that badly needs D support that handles it differently? > Why not define it just to shift by the requested number of bits? Because it would turn code that is currently z = x << y; to z = y < (8*sizeof(x)) ? x << y : 0; On many platforms. Given that you seldom want to shift by a custom amount, and that it could eliminate some bugs, it might be a reasonable trade-off. > > Any extra processor instructions to make it behave correctly for cases where this number > >= 32 would be the part of the backend code generation. And if the right operand is a > compile-time constant (as it probably is usually), these extra instructions > can be > eliminated or at least optimised to the particular value. > >> Are there any practical downsides to making the behavior defined? (Except >> that >> the CTFE Code would have to be fixed). I think Java does it too. > > Apparently Java shifts are modulo the number of bits in the type of the left operand. Or > something like that. You'd think it was an oversight in the original implementation that > was kept for bug compatibility, but you could well ask how they dealt with finding the > behaviour to be machine dependent (contrary to the whole philosophy of Java). > > Stewart. I don't even care so much about what the result is, but I feel that saying "the program is in error"/"the behavior is undefined", when actually you'd just get back some number is not optimal. (it allows the compiler to do anything if that case occurs) I would prefer to make the behavior at least implementation-defined (just a formal change on the D website) or even defined with some runtime-overhead. Timon