Re: [ANN] Lua 5.3.0 (work2) now available

[Jay Carlson <nop@...>]

(I think my tablet ate my message, so I'm starting with the last draft I can find.)

On Mar 25, 2014 4:14 PM, "Roberto Ierusalimschy" <roberto@inf.puc-rio.br> wrote:
>
> > Well for me some years ago I had to code up a (very) fast CCITT group
> > 3 fax decoder that needed to handle a huffman compressed token stream
> > .. with tokens varying in length from 3 to 13 bits. Lots of shifts
> > and masking involved here, which were table driven by shift factors
> > all over the place. Transcoding that (from C) to Lua without shifts
> > would involve working though all the tables replacing the shifts with
> > powers of two factors, then searching out all functions that had shift
> > factors as arguments etc. Certainly more work than would be involved
> > if Lua had shift operators. That said, for this project I cannot
> > recall needing arithmetic shift, just logical.
>
> The point of my question was whether Lua should have logical or
> arithmetic shift, not whether Lua should have shifts. This case
> seems to favor logical shifts.

I don't know. Most of the arguments seem to be about bitfield insertion and extraction. The shift ops are what the hardware implements but for a bytecoded language this is unimportant. You can build left and right shift out of mask-and-extract and mask-and-insert trivially.

It is not super-efficient to write "x >> 24 & 0xff" or "r=x ~ (x~n<<4) & 0xf0". (The latter is an idiom for "select which bits of x and y to merge together.) It's cheaper to have a 3-ary operator in the VM for the first. The full generality of mask-and-insert may not be necessary; people like to write x=0, which would then be a 3-ary n<<b&mask.

Note that the process of constructing shifts out of insert/extract contains a ~0 term: (x>>n)&~0, and 0~(0~x<<n)&~0.

For once I do not have a suggested syntax. But I do think the shift/mask pairs are so common they might be a better base case.

Jay