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

Shhhh... ;o)

(Seriously tho, well-spotted!)

Nicely found~

This has been fixed in 0.1.12:

Fixed: cpu cycle exploit using peek4 with no parameters

There's a similar bug with all(), e.g. all(t), where t is {1}, costs negative cycles.