Log In  

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

Shhhh... ;o)

(Seriously tho, well-spotted!)

P#60206 2018-12-21 14:25

Nicely found~

P#60346 2018-12-25 17:05
1

This has been fixed in 0.1.12:

Fixed: cpu cycle exploit using peek4 with no parameters
P#63437 2019-04-12 08:46
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]

Follow Lexaloffle:          
Generated 2024-03-28 13:33:15 | 0.006s | Q:15