Removing undefined behavior of bitshifts

[Timon Gehr]

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