@zep:
Is this really the expected behavior?
> ?shl(1,32) 1 > ?shr(1,32) 1 |
I'd have expected 0 in both cases.
It works correctly for lesser shifts that push the 1 off of either end:
> ?shl(1,31) 0 > ?shr(1,31) 0 |
Seems like you're doing a modulo of the shift with 32:
> ?shl(1,33) 2 > ?shr(1,33) 0.5 |
Doesn't feel like the right behavior to me. Like, in assembly language, maybe, but not in a higher language.
PS: It would be nice to have bith arithmetic and logical shifts right, btw. :)
I kind of like this behavior since it lets you catch bits that would otherwise fall off right?
Am I understanding that correctly?
My only frame of reference is 6502 asm. There, bits fall off onto a Carry flag (single bit register) and then wrap if you rotate/shift again. You can use this for different effects. And at least on an 8 bit register it comes in handy a lot.
With your examples it could all be a coincidence though so maybe it is straight up taking the argument as a mod of the limit for shifting. Do other values follow this behavior too?
Edit: Yeah, after testing it out a bit I realized what I was thinking wouldn't make sense here. After testing with some larger numbers, I'm not 100% what it is doing, exactly. But here are some tests for smarter people to analyze:
(255<--0):255 (255<--1):510 (255<--2):1020 (255<--3):2040 (255<--4):4080 (255<--5):8160 (255<--6):16320 (255<--7):32640 (255<--8):-256 (255<--9):-512 (255<--10):-1024 (255<--11):-2048 (255<--12):-4096 (255<--13):-8192 (255<--14):-16384 (255<--15):-32768 (255<--16):0 (255<--17):0 (255<--18):0 (255<--19):0 (255<--20):0 (255<--21):0 (255<--22):0 (255<--23):0 (255<--24):0 (255<--25):0 (255<--26):0 (255<--27):0 (255<--28):0 (255<--29):0 (255<--30):0 (255<--31):0 (255<--32):255 (255-->0):255 (255-->1):127.5 (255-->2):63.75 (255-->3):31.875 (255-->4):15.938 (255-->5):7.969 (255-->6):3.984 (255-->7):1.992 (255-->8):0.9961 (255-->9):0.4981 (255-->10):0.249 (255-->11):0.1245 (255-->12):0.06226 (255-->13):0.03114 (255-->14):0.01557 (255-->15):0.00779 (255-->16):0.003899 (255-->17):0.001945 (255-->18):0.0009689 (255-->19):0.0004807 (255-->20):0.0002365 (255-->21):0.0001144 (255-->22):5.341e-005 (255-->23):2.289e-005 (255-->24):0 (255-->25):0 (255-->26):0 (255-->27):0 (255-->28):0 (255-->29):0 (255-->30):0 (255-->31):0 (255-->32):255 |
(1<--0):1 (1<--1):2 (1<--2):4 (1<--3):8 (1<--4):16 (1<--5):32 (1<--6):64 (1<--7):128 (1<--8):256 (1<--9):512 (1<--10):1024 (1<--11):2048 (1<--12):4096 (1<--13):8192 (1<--14):16384 (1<--15):-32768 (1<--16):0 (1<--17):0 (1<--18):0 (1<--19):0 (1<--20):0 (1<--21):0 (1<--22):0 (1<--23):0 (1<--24):0 (1<--25):0 (1<--26):0 (1<--27):0 (1<--28):0 (1<--29):0 (1<--30):0 (1<--31):0 (1<--32):1 (1-->0):1 (1-->1):0.5 (1-->2):0.25 (1-->3):0.125 (1-->4):0.06251 (1-->5):0.03126 (1-->6):0.01563 (1-->7):0.00782 (1-->8):0.003914 (1-->9):0.001961 (1-->10):0.0009842 (1-->11):0.0004959 (1-->12):0.0002518 (1-->13):0.0001297 (1-->14):6.866e-005 (1-->15):3.815e-005 (1-->16):2.289e-005 (1-->17):0 (1-->18):0 (1-->19):0 (1-->20):0 (1-->21):0 (1-->22):0 (1-->23):0 (1-->24):0 (1-->25):0 (1-->26):0 (1-->27):0 (1-->28):0 (1-->29):0 (1-->30):0 (1-->31):0 (1-->32):1 |
(2<--0):2 (2<--1):4 (2<--2):8 (2<--3):16 (2<--4):32 (2<--5):64 (2<--6):128 (2<--7):256 (2<--8):512 (2<--9):1024 (2<--10):2048 (2<--11):4096 (2<--12):8192 (2<--13):16384 (2<--14):-32768 (2<--15):0 (2<--16):0 (2<--17):0 (2<--18):0 (2<--19):0 (2<--20):0 (2<--21):0 (2<--22):0 (2<--23):0 (2<--24):0 (2<--25):0 (2<--26):0 (2<--27):0 (2<--28):0 (2<--29):0 (2<--30):0 (2<--31):0 (2<--32):2 (2-->0):2 (2-->1):1 (2-->2):0.5 (2-->3):0.25 (2-->4):0.125 (2-->5):0.06251 (2-->6):0.03126 (2-->7):0.01563 (2-->8):0.00782 (2-->9):0.003914 (2-->10):0.001961 (2-->11):0.0009842 (2-->12):0.0004959 (2-->13):0.0002518 (2-->14):0.0001297 (2-->15):6.866e-005 (2-->16):3.815e-005 (2-->17):2.289e-005 (2-->18):0 (2-->19):0 (2-->20):0 (2-->21):0 (2-->22):0 (2-->23):0 (2-->24):0 (2-->25):0 (2-->26):0 (2-->27):0 (2-->28):0 (2-->29):0 (2-->30):0 (2-->31):0 (2-->32):2 |
(5<--0):5 (5<--1):10 (5<--2):20 (5<--3):40 (5<--4):80 (5<--5):160 (5<--6):320 (5<--7):640 (5<--8):1280 (5<--9):2560 (5<--10):5120 (5<--11):10240 (5<--12):20480 (5<--13):-24576 (5<--14):16384 (5<--15):-32768 (5<--16):0 (5<--17):0 (5<--18):0 (5<--19):0 (5<--20):0 (5<--21):0 (5<--22):0 (5<--23):0 (5<--24):0 (5<--25):0 (5<--26):0 (5<--27):0 (5<--28):0 (5<--29):0 (5<--30):0 (5<--31):0 (5<--32):5 (5-->0):5 (5-->1):2.5 (5-->2):1.25 (5-->3):0.625 (5-->4):0.3125 (5-->5):0.1563 (5-->6):0.07813 (5-->7):0.03907 (5-->8):0.01954 (5-->9):0.009773 (5-->10):0.00489 (5-->11):0.002449 (5-->12):0.001228 (5-->13):0.000618 (5-->14):0.0003128 (5-->15):0.0001602 (5-->16):8.392e-005 (5-->17):3.815e-005 (5-->18):2.289e-005 (5-->19):0 (5-->20):0 (5-->21):0 (5-->22):0 (5-->23):0 (5-->24):0 (5-->25):0 (5-->26):0 (5-->27):0 (5-->28):0 (5-->29):0 (5-->30):0 (5-->31):0 (5-->32):5 |
I think what it comes down to is that it doesn't work the way you'd expect it to, so that's ultimately what needs fixing, regardless of what's actually wrong under the hood.
What's not certain is whether this is an issue in lua itself or in pico-8's custom lua intrinsics.
It's not a problem with the lua language itself. In other implementations, the Lua bitshift operations work like you would expect.
Here's some fun with Lua.org's lua demo :
for ii=1,256 do print( ii .. " : " .. (1 << ii) ) end |
This produces the expected values until ii=63. and ii>=64 all come up with zero.
I'll bet the bug is exactly as you say : A modulus where there shouldn't be one.
I just ran into this bug - will check to see if maybe it has been fixed. In my case I'm finding shr(75,5) == 2.344... what??? It should equal 2. :-(
==update==
After searching the support pages I read that it is expected that shr returns a fraction because of the internal 16.16 fixed point representation. The more you know... :-)
[Please log in to post a comment]
