lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index] 

On 10/14/2010 9:13 PM, David Manura wrote:

On Thu, Oct 14, 2010 at 1:22 AM, KHMan 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)
This is not for deflate, is it? There is no real reason to be requesting 0 bits or 32 bit in deflate, because the original pkzip architecture is designed for 64KB segments. Huffman codes are limited in length as well, etc. The encoding and decoding process has no real reason to be asking for 0 or 32 bits... ???
Just a little puzzled as to why a compression algorithm needs to call to get 0 bits -- which sounds like a no-op. Yet to see any algorithm that does it. If it's not for deflate, then getting 32 bits can just skip everything and use a faster call. 

--
Cheers,
Kein-Hong Man (esq.)
Kuala Lumpur, Malaysia