Re: native code for bitwise operators in LUA

[HyperHacker <hyperhacker@...>]

On Thu, Nov 3, 2011 at 04:00, Dirk Laurie <dirk.laurie@gmail.com> wrote:
> 2011/11/2 Luiz Henrique de Figueiredo <lhf@tecgraf.puc-rio.br>:
>>
>> the bit32 library is meant to make bit manipulation possible in Lua, not to make it fast.
>>
>
> That is an important point.  But the point in a previous thread about
> operators corresponding to metamethods __and, __or, __xor and __not,
> which could be supplied for some objects (arrays were mentioned) fits
> in very nicely with their mapping to bit.band, bit.bor, bit.xor and
> bit.bnot.  The other bitwise operators (shifts and rotates) do not
> appear to be as generally useful.
>
> Dirk
>
>

Eh, it'd seem odd to include only some bitwise operators. They're
often used together in complex operations.

To give an idea what I mean when I keep saying "complex operations",
what I'm mostly doing with bit ops in Lua is reimplementing low-level
rendering code disassembled from Nintendo 64 games. Examples of what
the code ends up looking like with infix bit ops:

VtxCache[i] = {
	X = bytes.tos16(vseg[vaddr  ], vseg[vaddr+1]),
	Y = bytes.tos16(vseg[vaddr+2], vseg[vaddr+3]),
	Z = bytes.tos16(vseg[vaddr+4], vseg[vaddr+5]),
	S = s / (32 << TileCache[0].SMask),
	T = t / (32 << TileCache[0].TMask),
	R = vseg[vaddr+10], G = vseg[vaddr+11],
	B = vseg[vaddr+12], A = vseg[vaddr+13] }

DrawPolys({{param[5] >> 1, param[6] >> 1, param[7] >> 1}})
--note that x >> 1 can't simply be changed to x / 2;
--it'd have to be math.floor(x / 2)

local idx = param[4] & 7
TileCache[idx] = {
    Format = TextureFormat[param[1] >> 5],
    Size = (param[1] >> 3) & 3,
    Line = ((param[1] & 3) << 7) | (param[2] >> 1),
    TMem = ((param[2] & 1) << 8) | param[3],
    Palette = param[5] >> 4,
    TFlags = (param[5] >> 2) & 3,
    TMask = ((param[5] & 3) << 2) | (param[6] >> 6),
    TShift = (param[6] >> 2) & 15,
    SFlags = param[6] & 3,
    SMask = param[7] >> 4,
    SShift = param[7] & 0xF }

Some of this code might be a bit more complex than necessary due to
compiler optimizations not being reversed during the decompliation,
but you can see how ugly it is already. Trying to port it to using the
bit library is very error-prone and makes the code even more ugly and
hard to follow.

-- 
Sent from my toaster.