native code for bitwise operators in LUA

classic Classic list List threaded Threaded
26 messages Options
12
Reply | Threaded
Open this post in threaded view
|

native code for bitwise operators in LUA

Ing. Jan Supuka SBM
In newest LUA 5.2 beta is implemented UNSIGNED INTEGER type and library
bit32 for bitwise operations.
BEAUTIFULL !

But I don't like write
     a = bit32.bor(bit32.band(5,2345),bit32.band(23,7))
instead of
     a = 5&2345|23&7
that's why I rework source codes ( lua-5.2.0-beta.tar.gz [NEW]    
2011-07-08
                                 
http://www.lua.org/work/lua-5.2.0-beta.tar.gz )
to use "native" operators (based on
http://www.wra1th.plus.com/lua/risclua.html source code) :
     band &
     bor     |
     bxor    ^^
     lshift <<
     rshift >>
     bnot    ~
and my own logical operators:
     and &&
     or      ||
     not     !

All source code changes are dependent on (luaconfig.h)
#define GCW_BIT
/*
GCW_BIT: Use bit library.
This extends virtual machine with bitwise operations
&,|, ^^, ~, <<, >> and provides corresponding events.
Warning! Makes code non-portable.
Affects c.lvm, c.lcode, c.lopcodes, c.ltm
c.llex, c.lparser, h.lcode, h.lopcodes
h.ltm, h.llex, h.luaconf.

additionally NUM_logical operators ( return numerical (1,0), not boolean
values )
!,&&,||
*/

IMPORTANT:   in standart LUA is not possible use boolean (true,false) in
arithmetical operations,
but I need it.
On (lvm.c line:375) is it possible (unremark) allow using booleans only
for new operators.
------------------------------
Need tests, if all is correct.
------------------------------

SOURCE:
http://sourceforge.net/projects/lualubit/files/
BASIC TEST ... approximately 5x faster native versus bit32.bxxx
operators,  more readable LUA source




Reply | Threaded
Open this post in threaded view
|

Re: native code for bitwise operators in LUA

Attila-3
Wish the standard Lua distribution contain these new things... I think  
many of us would appreciate it.

Regards,
Attila

2011.11.02. 16:03:43 dátumon Ing. Jan Supuka SBM  
<[hidden email]> írta:

> In newest LUA 5.2 beta is implemented UNSIGNED INTEGER type and library  
> bit32 for bitwise operations.
> BEAUTIFULL !
>
> But I don't like write
>      a = bit32.bor(bit32.band(5,2345),bit32.band(23,7))
> instead of
>      a = 5&2345|23&7
> that's why I rework source codes ( lua-5.2.0-beta.tar.gz [NEW]      
> 2011-07-08
>                                  
> http://www.lua.org/work/lua-5.2.0-beta.tar.gz )
> to use "native" operators (based on  
> http://www.wra1th.plus.com/lua/risclua.html source code) :
>      band &
>      bor     |
>      bxor    ^^
>      lshift <<
>      rshift >>
>      bnot    ~
> and my own logical operators:
>      and &&
>      or      ||
>      not     !
>
> All source code changes are dependent on (luaconfig.h)
> #define GCW_BIT
> /*
> GCW_BIT: Use bit library.
> This extends virtual machine with bitwise operations
> &,|, ^^, ~, <<, >> and provides corresponding events.
> Warning! Makes code non-portable.
> Affects c.lvm, c.lcode, c.lopcodes, c.ltm
> c.llex, c.lparser, h.lcode, h.lopcodes
> h.ltm, h.llex, h.luaconf.
>
> additionally NUM_logical operators ( return numerical (1,0), not boolean  
> values )
> !,&&,||
> */
>
> IMPORTANT:   in standart LUA is not possible use boolean (true,false) in  
> arithmetical operations,
> but I need it.
> On (lvm.c line:375) is it possible (unremark) allow using booleans only  
> for new operators.
> ------------------------------
> Need tests, if all is correct.
> ------------------------------
>
> SOURCE:
> http://sourceforge.net/projects/lualubit/files/
> BASIC TEST ... approximately 5x faster native versus bit32.bxxx  
> operators,  more readable LUA source
>
>

Reply | Threaded
Open this post in threaded view
|

Re: native code for bitwise operators in LUA

liam mail
In reply to this post by Ing. Jan Supuka SBM
2011/11/2 Ing. Jan Supuka SBM <[hidden email]>:

> In newest LUA 5.2 beta is implemented UNSIGNED INTEGER type and library
> bit32 for bitwise operations.
> BEAUTIFULL !
>
> But I don't like write
>    a = bit32.bor(bit32.band(5,2345),bit32.band(23,7))
> instead of
>    a = 5&2345|23&7
> that's why I rework source codes ( lua-5.2.0-beta.tar.gz [NEW]
> 2011-07-08
>                                http://www.lua.org/work/lua-5.2.0-beta.tar.gz
> )
> to use "native" operators (based on
> http://www.wra1th.plus.com/lua/risclua.html source code) :
>    band &
>    bor     |
>    bxor    ^^
>    lshift <<
>    rshift >>
>    bnot    ~
> and my own logical operators:
>    and &&
>    or      ||
>    not     !
>
> All source code changes are dependent on (luaconfig.h)
> #define GCW_BIT
> /*
> GCW_BIT: Use bit library.
> This extends virtual machine with bitwise operations
> &,|, ^^, ~, <<, >> and provides corresponding events.
> Warning! Makes code non-portable.
> Affects c.lvm, c.lcode, c.lopcodes, c.ltm
> c.llex, c.lparser, h.lcode, h.lopcodes
> h.ltm, h.llex, h.luaconf.
>
> additionally NUM_logical operators ( return numerical (1,0), not boolean
> values )
> !,&&,||
> */
>
> IMPORTANT:   in standart LUA is not possible use boolean (true,false) in
> arithmetical operations,
> but I need it.
> On (lvm.c line:375) is it possible (unremark) allow using booleans only for
> new operators.
> ------------------------------
> Need tests, if all is correct.
> ------------------------------
>
> SOURCE:
> http://sourceforge.net/projects/lualubit/files/
> BASIC TEST ... approximately 5x faster native versus bit32.bxxx operators,
>  more readable LUA source
>
>
>
>
>

Thanks it looks interesting although on first try to compile I get an
error about luaopen_mathx being undefined, is this a private maths
library?* So I have not yet run the speed tests but I would recommend
some changes in both Rio Lua usage and your own.
Such as:
Don't use io operations inside a profile test
Use locals instead of globals
Be nice to Rio Lua and cache bit32.band et al to locals ie local band
= bit32.band

* also a warning is generated for lvm.c:380 suggest parentheses around
&& within ||

Liam

Reply | Threaded
Open this post in threaded view
|

Re: native code for bitwise operators in LUA

liam mail
On 2 November 2011 20:24, liam mail <[hidden email]> wrote:

> 2011/11/2 Ing. Jan Supuka SBM <[hidden email]>:
>> In newest LUA 5.2 beta is implemented UNSIGNED INTEGER type and library
>> bit32 for bitwise operations.
>> BEAUTIFULL !
>>
>> But I don't like write
>>    a = bit32.bor(bit32.band(5,2345),bit32.band(23,7))
>> instead of
>>    a = 5&2345|23&7
>> that's why I rework source codes ( lua-5.2.0-beta.tar.gz [NEW]
>> 2011-07-08
>>                                http://www.lua.org/work/lua-5.2.0-beta.tar.gz
>> )
>> to use "native" operators (based on
>> http://www.wra1th.plus.com/lua/risclua.html source code) :
>>    band &
>>    bor     |
>>    bxor    ^^
>>    lshift <<
>>    rshift >>
>>    bnot    ~
>> and my own logical operators:
>>    and &&
>>    or      ||
>>    not     !
>>
>> All source code changes are dependent on (luaconfig.h)
>> #define GCW_BIT
>> /*
>> GCW_BIT: Use bit library.
>> This extends virtual machine with bitwise operations
>> &,|, ^^, ~, <<, >> and provides corresponding events.
>> Warning! Makes code non-portable.
>> Affects c.lvm, c.lcode, c.lopcodes, c.ltm
>> c.llex, c.lparser, h.lcode, h.lopcodes
>> h.ltm, h.llex, h.luaconf.
>>
>> additionally NUM_logical operators ( return numerical (1,0), not boolean
>> values )
>> !,&&,||
>> */
>>
>> IMPORTANT:   in standart LUA is not possible use boolean (true,false) in
>> arithmetical operations,
>> but I need it.
>> On (lvm.c line:375) is it possible (unremark) allow using booleans only for
>> new operators.
>> ------------------------------
>> Need tests, if all is correct.
>> ------------------------------
>>
>> SOURCE:
>> http://sourceforge.net/projects/lualubit/files/
>> BASIC TEST ... approximately 5x faster native versus bit32.bxxx operators,
>>  more readable LUA source
>>
>>
>>
>>
>>
>
> Thanks it looks interesting although on first try to compile I get an
> error about luaopen_mathx being undefined, is this a private maths
> library?* So I have not yet run the speed tests but I would recommend
> some changes in both Rio Lua usage and your own.
> Such as:
> Don't use io operations inside a profile test
> Use locals instead of globals
> Be nice to Rio Lua and cache bit32.band et al to locals ie local band
> = bit32.band
>
> * also a warning is generated for lvm.c:380 suggest parentheses around
> && within ||
>
> Liam
>

Oh, I forgot to say did you have a Lua Uppercase Accident :)
Lua != LUA

Liam

Reply | Threaded
Open this post in threaded view
|

Re: native code for bitwise operators in LUA

Luiz Henrique de Figueiredo
In reply to this post by liam mail
> I get an error about luaopen_mathx being undefined, is this a private
> maths library?

Perhaps it's http://www.tecgraf.puc-rio.br/~lhf/ftp/lua/#lmathx ?

Reply | Threaded
Open this post in threaded view
|

Re: native code for bitwise operators in LUA

liam mail
On 2 November 2011 20:41, Luiz Henrique de Figueiredo
<[hidden email]> wrote:
>> I get an error about luaopen_mathx being undefined, is this a private
>> maths library?
>
> Perhaps it's http://www.tecgraf.puc-rio.br/~lhf/ftp/lua/#lmathx ?
>
>
Perhaps it is, I commented it out just so I could run the speed test. WOW

https://gist.github.com/1334864

Reply | Threaded
Open this post in threaded view
|

Re: native code for bitwise operators in LUA

Luiz Henrique de Figueiredo
> I commented it out just so I could run the speed test. WOW
>
> https://gist.github.com/1334864

The speed difference you see is expected, of course.

Surely any operation can be made faster by providing a VM instruction
for it. The hard decision is what to include, which reminds me of
something I heard about I think it was Word: no one uses more than 5%
of Word, by each person uses a different 5%, hence the bloat.

If you find yourself writing bit-intensive programs in Lua, perhaps
a dedicated C function is recommended. I understand that not all Lua
environments can load C libraries (WoW comes to mind); the bit32 library
is meant to make bit manipulation possible in Lua, not to make it fast.

Reply | Threaded
Open this post in threaded view
|

Re: native code for bitwise operators in LUA

liam mail
On 2 November 2011 20:59, Luiz Henrique de Figueiredo
<[hidden email]> wrote:
>> I commented it out just so I could run the speed test. WOW
>>
>> https://gist.github.com/1334864
>
> The speed difference you see is expected, of course.
>
> Surely any operation can be made faster by providing a VM instruction
> for it.
Yes of course a speed up was expected but it is much more than the
advertised "approximately 5x faster native versus bit32.bxxx
operators"

> If you find yourself writing bit-intensive programs in Lua, perhaps
> a dedicated C function is recommended. I understand that not all Lua
> environments can load C libraries (WoW comes to mind); the bit32 library
> is meant to make bit manipulation possible in Lua, not to make it fast.
>
I can sort of understand that philosophy yet bit operations are meant
to be fast, although I can maybe understand why these operators were
not used and also why they are not vm op codes. Having said that it
would be nice to have them like so in a Rio release but then everybody
wants everything in a Rio release :)

Liam

Reply | Threaded
Open this post in threaded view
|

Re: native code for bitwise operators in LUA

Duncan Cross
In reply to this post by Luiz Henrique de Figueiredo
On Wed, Nov 2, 2011 at 8:59 PM, Luiz Henrique de Figueiredo
<[hidden email]> wrote:
> If you find yourself writing bit-intensive programs in Lua, perhaps
> a dedicated C function is recommended.

I disagree - I believe the recommended first-instinct now should be to
use LuaJIT if you want to do intensive stuff in Lua. It's not always
possible, but then custom C isn't always possible either.

-Duncan

Reply | Threaded
Open this post in threaded view
|

Re: native code for bitwise operators in LUA

Patrick Rapin
In reply to this post by liam mail
I do use quite a lot bitwise operators in C++.
In Lua 5.1, bit operations missed me a lot so I wrote a bit library
(instead of searching for an existent one).
So I am happy that a standard bit32 library now appears in Lua 5.2.

However, I am clearly against introducing new operators and new VM op
codes for bit operations:
- Lua has very few punctuation operators, privileging key words.
- Lua lacked bitwise operations during 18 years; I doubt that they
became suddenly so important to change the grammar for them
- Lua always favors small implementation code when possible. New
opcodes and operators are harder to introduce, and cannot be
"opted-out".
- Even MATLAB doesn't have operators for bit operations
- If you want speed, use LuaJIT

Reply | Threaded
Open this post in threaded view
|

Re: native code for bitwise operators in LUA

Rena
On Wed, Nov 2, 2011 at 15:43, Patrick Rapin <[hidden email]> wrote:

> I do use quite a lot bitwise operators in C++.
> In Lua 5.1, bit operations missed me a lot so I wrote a bit library
> (instead of searching for an existent one).
> So I am happy that a standard bit32 library now appears in Lua 5.2.
>
> However, I am clearly against introducing new operators and new VM op
> codes for bit operations:
> - Lua has very few punctuation operators, privileging key words.
> - Lua lacked bitwise operations during 18 years; I doubt that they
> became suddenly so important to change the grammar for them
> - Lua always favors small implementation code when possible. New
> opcodes and operators are harder to introduce, and cannot be
> "opted-out".
> - Even MATLAB doesn't have operators for bit operations
> - If you want speed, use LuaJIT
>
>

I've often wished Lua had infix bitwise operators. There are patches
for it (such as this one), but such significant patches make it not
really Lua anymore. You can also hack some metatable tricks to make
things like (1) '<<' (3) work, but that's still ugly (and I dread to
think of its efficiency). The bit library only provides prefix
operators which I find quite a bit harder to read when dealing with
complex operations.

This really seems like one of the rare cases where adding a feature
would be a significant improvement while only slightly increasing the
code size.

As for this particular patch, I see ~ and !... that doesn't change the
meaning of ~=, does it? Even if not, it makes it a bit confusing, with
~ now having different meanings in different contexts.

--
Sent from my toaster.

Reply | Threaded
Open this post in threaded view
|

Re: native code for bitwise operators in LUA

Miles Bader-2
In reply to this post by Duncan Cross
Duncan Cross <[hidden email]> writes:
>> If you find yourself writing bit-intensive programs in Lua, perhaps
>> a dedicated C function is recommended.
>
> I disagree - I believe the recommended first-instinct now should be to
> use LuaJIT if you want to do intensive stuff in Lua. It's not always
> possible, but then custom C isn't always possible either.

It of course depends on your portability goals.  Presuming you have
the infrastructure to support a custom C function, it will probably be
more portable than an assumption of LuaJIT support.... :]

If you're fine with your code only running on x86+ppc+? then LuaJIT is
obviously a great way to crank up the speed with minimal effort!

-Miles

--
Un-American, adj. Wicked, intolerable, heathenish.

Reply | Threaded
Open this post in threaded view
|

Re: native code for bitwise operators in LUA

Mike Panetta
In reply to this post by Rena


On Wed, Nov 2, 2011 at 7:07 PM, HyperHacker <[hidden email]> wrote:
On Wed, Nov 2, 2011 at 15:43, Patrick Rapin <[hidden email]> wrote:

> - If you want speed, use LuaJIT
>
>


I keep seeing people say that but, for example, does LuaJIT compile and run on bare metal Cortex-Mx processors?  This is a platform where natural bitops would definitely be welcome, but something like LuaJIT is probably not an option.

Mike
Reply | Threaded
Open this post in threaded view
|

Re: native code for bitwise operators in LUA

Daurnimator
On 3 November 2011 11:04, Mike Panetta <[hidden email]> wrote:
> I keep seeing people say that but, for example, does LuaJIT compile and run
> on bare metal Cortex-Mx processors?  This is a platform where natural bitops
> would definitely be welcome, but something like LuaJIT is probably not an
> option.
>
> Mike
>

>From http://lua-users.org/lists/lua-l/2009-08/msg00180.html I'm going
to assume no.
but, elua does exist on cortex m3...
http://www.eluaproject.net/doc/v0.8/en_tc_cortex.html and they use the
bitlib happily http://www.eluaproject.net/doc/v0.8/en_refman_gen_bit.html

Reply | Threaded
Open this post in threaded view
|

Re: native code for bitwise operators in LUA

Luiz Henrique de Figueiredo
In reply to this post by Duncan Cross
> > If you find yourself writing bit-intensive programs in Lua, perhaps
> > a dedicated C function is recommended.
>
> I disagree - I believe the recommended first-instinct now should be to
> use LuaJIT if you want to do intensive stuff in Lua. It's not always
> possible, but then custom C isn't always possible either.

What I had in mind was things like MD5 or SHA2 or other crypto stuff:
well-defined bit-intensive functions that are readily available as
C functions.

Reply | Threaded
Open this post in threaded view
|

Re: native code for bitwise operators in LUA

Ing. Jan Supuka SBM
In reply to this post by liam mail
Dňa 2011-11-02 21:27, liam mail wrote / napísal(a):

> On 2 November 2011 20:24, liam mail<[hidden email]>  wrote:
>>
>> Thanks it looks interesting although on first try to compile I get an
>> error about luaopen_mathx being undefined, is this a private maths
>> library?* So I have not yet run the speed tests but I would recommend
>> some changes in both Rio Lua usage and your own.
>> Such as:
>> Don't use io operations inside a profile test
>> Use locals instead of globals
>> Be nice to Rio Lua and cache bit32.band et al to locals ie local band
>> = bit32.band
>>
>> * also a warning is generated for lvm.c:380 suggest parentheses around
>> &&  within ||
>>
>> Liam
>>
> Oh, I forgot to say did you have a Lua Uppercase Accident :)
> Lua != LUA
>
> Liam
>
Thanks a lot of trying .
readme.txt and project description ... Lua Uppercase Accident ... CORRECTED
lmathx .... sorry, mistake in (manually changed) makefile (I use
CodeLite) ... CORRECTED
lvm.c ... suggested parantheses ... CORRECTED
testluabit.lua ... using locals ... PROVIDED as third test

http://sourceforge.net/projects/lualubit/files updated

Some explanation for using "special" bitwise operators
I'm working on SCADA project, where I need scripting language for
'conditioning' raw values from IO devices
Now 8 500 "upper level" values assigned by "Lua user defined conditioing
script" to app. 14 000 raw values
(now like in testcalc.lua, but offered possibility for more desribed and
more complicated scripts) .
App. 10 000 raw values are updated in half of second !. And scripts must
be calculated practically immediately.
And most of them need bitwise operations.
Near future ... 30 000 "upper level" values conditioned from app. 50 000
raw values from IO devices.
SPEED is CRITICAL.
Setting/reseting bit signal in STATUS(long int) like M_ALARM_MIN,
M_ALARM_MAX, OUT_OF_ORDER, ERROR_STATE .... ,
conditional calculation based on these and others bit signals
(f.e. archiving M_ARCH_10sec, M_ARCH_1minute, M_ARCH_1hour,
M_ARCH_everySTATUSchange)
all need fastest possible bitwise calculations (min. 20 bitwise opers /
1 value / 0.5sec ==> 340000 opers/sec min.) .

Very nice will be "totally scripted system" with none specially compiled
code.
I tried write SCADA_calcul_core in PHP (native bitwise) ... 2 seconds
per cycle ... slow
I tried write SCADA_calcul_core in Lua (bit32 lib local defined bxxx
functions) ... 3 !!!! seconds per cycle ... slower than PHP !!!
That's why I start working on lualubit project.

For now it must be C compiled SCADA_calcul_core with Lua conditional
scripts (in-time USER DEFINITION strictly required),
fast bitwise operators are needed, otherwise using Lua language is
practically impossible in my case.

Dňa 2011-11-02 22:43, Patrick Rapin wrote / napísal(a):

> I do use quite a lot bitwise operators in C++.
> In Lua 5.1, bit operations missed me a lot so I wrote a bit library
> (instead of searching for an existent one).
> So I am happy that a standard bit32 library now appears in Lua 5.2.
>
> However, I am clearly against introducing new operators and new VM op
> codes for bit operations:
> - Lua has very few punctuation operators, privileging key words.
> - Lua lacked bitwise operations during 18 years; I doubt that they
> became suddenly so important to change the grammar for them
> - Lua always favors small implementation code when possible. New
> opcodes and operators are harder to introduce, and cannot be
> "opted-out".
> - Even MATLAB doesn't have operators for bit operations
> - If you want speed, use LuaJIT
>

Completely rewrite all long time succesfully worked code logics to
achieve strict actual Lua compatibility ?
What reason ? ONLY argument ... lacked bitwise operators during 18 years ?
In Lua 5.2 beta are introduced UNSIGNED INT (again thanks !) ... maybe
signal to faster work without double/int conversion,
implementing bitwise library into core code ... signal, that bitwise
operators are 'good to have',
I hope, signal for possible introducing (not new, but missing, I thing)
native bitwise operators too.

In lualubit Lua variant implemented bitwise operators may or may not be
used.
Changing grammar is very low price for performance improvement.

Sizes (Windows 7 MinGW CodeLite ):
source code Lua 5.2 beta 537,072 bytes LuaLubit 553,650 bytes
release lua.exe Lua 5.2 beta 252 KB LuaLubit 276 KB



------------------------------
I am relative newbie in Lua language, and I have doubts, if lualubit is
completely correct,
especially in 'allow treat booleans as number in arithmetical operations
(for new/all operators)' ,
need help with testing
------------------------------
PS: lubit ... ľúbiť === to love (in Slovak)



Reply | Threaded
Open this post in threaded view
|

Re: native code for bitwise operators in LUA

Dirk Laurie-2
In reply to this post by Luiz Henrique de Figueiredo
2011/11/2 Luiz Henrique de Figueiredo <[hidden email]>:
>
> 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

Reply | Threaded
Open this post in threaded view
|

Re: native code for bitwise operators in LUA

Rena
On Thu, Nov 3, 2011 at 04:00, Dirk Laurie <[hidden email]> wrote:

> 2011/11/2 Luiz Henrique de Figueiredo <[hidden email]>:
>>
>> 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.

Reply | Threaded
Open this post in threaded view
|

Re: native code for bitwise operators in LUA

Luiz Henrique de Figueiredo
> Trying to port it to using the bit library is very error-prone

Perhaps there is a niche for a tool that converts infix bitwise
expressions in whatever syntax you prefer to Lua code using the bit
library. It's probably quite easy to write this tool with LPEG.

Reply | Threaded
Open this post in threaded view
|

Re: native code for bitwise operators in LUA

Rena
On Thu, Nov 3, 2011 at 18:31, Luiz Henrique de Figueiredo
<[hidden email]> wrote:
>> Trying to port it to using the bit library is very error-prone
>
> Perhaps there is a niche for a tool that converts infix bitwise
> expressions in whatever syntax you prefer to Lua code using the bit
> library. It's probably quite easy to write this tool with LPEG.
>
>

I've thought about doing similar: a function that just parses a string
like "x << (y | z)" and interprets it at runtime. Your idea though has
the advantage that you don't have to do any variable interpolation and
the parsing only needs to be done once.

--
Sent from my toaster.

12