Re: [ANN] Lua 5.2.0 (work1) now available

[Doug Rogers <doug.rogers@...>]

Mike Pall wrote:
> Doug Rogers wrote:
>> I'll need to go back and read your original reasoning on (*) 'Shift
>> counts should be masked by the bit width', because I would think the
>> masking should occur only for rotates. For shifts, the return value of a
>> overshift should be zero (or all ones, a.k.a. -1 according to the
>> Summary, for a sign-extended right shift with a sign bit of one).
> 
> Just check your own code base for usage examples of bit shifts.

Maybe I misunderstand you here. In all my bit-busting code, if the shift
is greater than the word size, I return 0 for the result of the shift.
It is as if the bits are simply shifted out of the register as in an LFSR.

For 32-bit entities, I would like ((w >> 20) >> 20) == (w >> 40),
whereas my reading of your requirement would make (w >> 40) == (w >> 8).

> On some CPUs (e.g. x86) the mask operation can even be optimized
> away by the C compiler or a Lua compiler. And as I've mentioned,
> it doesn't need a branch ...

Many, many years ago I found to my surprise and consternation that x86
shifting did nothing (or was undefined?) when the count is greater than
 or equal to the operand size. I remember singlestepping a debugger,
thinking the result was crazy. I opened the data book and was surprised
(well, not all that surprised) to see that I was the crazy one! Since
then I always check the size and make it behave as I describe above. I
realize it causes a branch to appear in the pipeline, but I prefer that
to the alternative, non-commutative masking of the shift.

I recognize that in some contexts it might be appropriate to mask the
count, but to me it seems like an issue of mathematical correctness.

Doug


______________________________________________________________________________________
The information contained in this email transmission may contain proprietary and business 
sensitive information.  If you are not the intended recipient, you are hereby notified that 
any review, dissemination, distribution or duplication of this communication is strictly 
prohibited.  Unauthorized interception of this e-mail is a violation of law.  If you are not 
the intended recipient, please contact the sender by reply email and immediately destroy all 
copies of the original message.

Any technical data and/or information provided with or in this email may be subject to U.S. 
export controls law.  Export, diversion or disclosure contrary to U.S. law is prohibited.  
Such technical data or information is not to be exported from the U.S. or given to any foreign
person in the U.S. without prior written authorization of Elbit Systems of America and the 
appropriate U.S. Government agency.