The function peek4() does not properly check its number of arguments, so calling it with no arguments will cost zero cycles. Combined with any other function that costs fewer cycles than its number of arguments, such as shl(), this can be exploited to reclaim CPU cycles.
Here is a function that reclaims n cycles:
function reclaim(n) for i=0,n/5 do shl(peek4(),peek4())shl(peek4(),peek4()) shl(peek4(),peek4())shl(peek4(),peek4()) shl(peek4(),peek4())shl(peek4(),peek4()) end end |
I do not know to what extent this can be exploited, but here is an example.
The following program runs at 15 FPS:
function _draw() for y=0,127 do m=3+rnd() for x=0,127 do pset(x,y,(x+7)*m%5) end end print(stat(7).." fps",1,1,7) end |
But this one runs at 30 FPS:
function _draw() for y=0,127 do m=3+rnd() for x=0,127 do pset(x,y,(x+7)*m%5) end reclaim(200) end print(stat(7).." fps",1,1,7) end |
P#60203 2018-12-21 14:20
1
There's a similar bug with all(), e.g. all(t), where t is {1}, costs negative cycles.
P#72949 2020-02-09 22:54
[Please log in to post a comment]