• Paul D. Anderson <paul.d.removethis.anderson comcast.andthis.net> Jun 11 2011

Paul D. Anderson <paul.d.removethis.anderson comcast.andthis.net> writes:

Timon Gehr Wrote:

 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


 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?


 
 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


  >= 32 would be the part of the backend code generation.  And if the right


 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


 something like that.  You'd think it was an oversight in the original


 was kept for bug compatibility, but you could well ask how they dealt with


 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


FWIW, the General Decimal Arithmetic specification (which I'm getting close to
implementing in D: it's always just one week away!) specifies that a shift or
rotate by more than the current precision is disallowed (returns a NaN).

I suppose the clarity on this point is possible because the context, including
the precision, is part of the specification, and the means to indicate failure
is also defined.

Unfortunately no such specification exists for integers (at least none that
doesn't start religious wars).

The clarity is offset, however, by  the requirement to shift by decimal digits,
not bits. Just a heads up that this won't be in the first release.

Paul