Re: bit.lshift and performance - luabitop v.s. lua-5.2.0-work4

[David Manura <dm.lua@...>]

On Thu, Oct 14, 2010 at 1:22 AM, KHMan <keinhong@gmail.com> wrote:
>On 10/14/2010 11:55 AM, David Manura wrote:
>> One downside is that the code
>>  local bits = bit.band(buffer, rshift(0xffffffff, 32 - nbits))
>>  buffer = bit.rshift(buffer, nbits)
>> now requires two special cases: nbits == 0 and nbits == 32.
> I'm sorry, I am interested in this particular problem, but it's very hard to
> parse the entire context of the brief description. I'm guessing there's
> involvement of Lua 5.1.x, Lua 5.2.x and LuaJIT, but I can't tell which is
> which or what's going on with the special cases.
>
> bit mask for data:
> ==================
> bit.rshift(0xffffffff, 32-0) => 0 (all masked, nothing returned)
> bit.rshift(0xffffffff, 32-16) => 65536 (1/2 masked, 1/2 returned)
> bit.rshift(0xffffffff, 32-32) => 4294967295 (none masked, all returned)
>
> data left in buffer:
> ====================
> bit.rshift(0x12345678, 0) => 0x12345678 (all left)
> bit.rshift(0x12345678, 16) => 0x00001234 (half left)
> bit.rshift(0x12345678, 32) = > 0x00000000 (none left)
>
> Well, it seems all right on Lua 5.2.x, at first glance. Do you have some
> sample output you can share?

My "now requires two special cases" refers to LuaBitOp (and by
implication code designed to be compatible with both LuaBitOp and Lua
5.2.0-work4, as is true of ModuleCompressDeflateLua).  For the above
cases, LuaBitOp gives

  bit.rshift(0xffffffff, 32-0) --> -1  (not 0)
  bit.rshift(0xffffffff, 32-16) --> 0xffff
  bit.rshift(0xffffffff, 32-32) --> -1
  bit.rshift(0x12345678, 0) --> 0x12345678
  bit.rshift(0x12345678, 16) --> 0x1234
  bit.rshift(0x12345678, 32) --> 0x12345678  (not 0)