Log In  

I would like to propose the following syntax extensions to PICO-8 for symmetry with the shorthand peek operators. Basically it means treating the peek operators result as an lvalue:

@x = y     -- short for poke(x,y)
%x = y     -- short for poke2(x,y)
$x = y     -- short for poke4(x,y)

@x += z       -- short for poke(x, @x + z)
%12 |= %42    -- short for poke2(12, %12 | %42)
$x >><= 4     -- short for poke4(x, $x >>< 4)
P#77838 2020-06-09 08:41

cryptic code to the max!

open question is cost for these operators - reading is now much faster than writing. these operators would change that balance.

P#77845 2020-06-09 10:33

Yes, this allows for even more cryptic code… but I don’t think it’s much of a slippery slope to allow @x=y or @x+=z if [email protected] and [email protected] are already valid.

P#77848 2020-06-09 11:37
:: shy

Absolutely! And I totally don't have an ulterior motive about getting faster poke calls. >.>

P#77916 2020-06-10 22:05
:: Felice
2

Would they actually be faster though? The reason we're given peek operators that cost fewer virtual cycles is to encourage us to use them, because the interpreter can handle them much faster than the old peek() calls. But this is because adding a unary op to the interpreter is easy and involves adding an actual opcode that can be interpreted directly, rather than having the overhead of a Lua function call, which does happen with peek() even though the guts of the function are presumably C code. It still has to handle Lua's custom stack/ABI for passing the address argument, whereas the opcode just gets its operand direct from the code stream with no shimming required.

Adding a new kind of lvalue that, instead of assigning to a lua variable, writes to custom "memory", probably isn't as easy, so I worry that it'd just end up as a search/replace for poke() and thus wouldn't be any faster under the hood, so we wouldn't be given a cycle incentive to use it.

That being said, it would still just be nice if it were orthogonal like that, even if it weren't any better perf-wise. :)

P#78297 2020-06-19 19:38 ( Edited 2020-06-19 20:00)
:: shy

Good point, @Felice. I'm hoping the shorthand poke() syntax could also be swapped with faster opcodes, since peek() already seems like a non-standard feature for Lua. Like, instead of just find/replacing @x=y with poke(x,y) and getting the function call overhead back, maybe it could pre-convert @x=y into [email protected]=y (to qualify for operator overloading), or just use an inline assignment? That syntax would be less intuitive, but could also be more optimizable.

Just on intuition, I thought this was why the peek operators were more efficient than the function calls, likely because it's inlined or those kinds of overloaded ops get cached somehow. It sounds like you have a better understanding of how the internals work, though, so I'll defer to your experience.

P#78800 2020-07-02 18:14

Actually I just tried to implement this for fun and while the opcode part was not as challenging as I thought, the problem is the parsing inconsistencies it creates: for instance “x=0 %x=y” is invalid because it is first parsed as “x=0 %x” which is valid Lua, then the “=y” part causes a syntax error. The choice of operators here makes it impossible to implement this in a consistent way.

P#78876 2020-07-04 15:55

[Please log in to post a comment]

Follow Lexaloffle:        
Generated 2021-06-15 20:16:22 | 0.019s | Q:17