I noticed that this:

x=-1

Costs one more token+cycle than this:

x=1

Which indicates that negative literals are never stored, instead being positive with a unary negation operator added.

Is this really as-intended or is it a parser bug? Regular Lua bytecode seems capable of storing signed values.

How do you know how how many cycles an operation takes?

Is there a way to know how many cycles occur per second?

see stat(1)

@springogeek: If you're careful, you can craft a fairly accurate benchmark program where you can drop in code and know how many cycles it takes. You just have to run the code many times, then divide the time() by the count and subtract the loop overhead (1cyc in a numeric FOR).

That's the gist of it, anyway.

The official Lua parser lexes the unary '-' operator and the Numeral as separate tokens. (Numeral doesn't start with an optional '-'.) So it parses to the unop expression of negating the positive numeral literal. See llex.c:read_numeral.

(Pico-8 uses a stock Lua interpreter, with preprocessor additions.)

@dddaaannn:

The current Lua parser collapses unary ops into constants where it can. Note the OPR_MINUS case below:

void luaK_prefix (FuncState *fs, UnOpr op, expdesc *e, int line) {
  static expdesc ef = {VKINT, {0}, NO_JUMP, NO_JUMP};  /* fake 2nd operand */
  switch (op) {
    case OPR_MINUS: case OPR_BNOT:
      if (constfolding(fs, op + LUA_OPUNM, e, &ef))
        break;
      /* FALLTHROUGH */
    case OPR_LEN:
      codeunexpval(fs, cast(OpCode, op + OP_UNM), e, line);
      break;
    case OPR_NOT: codenot(fs, e); break;
    default: lua_assert(0);
  }
}

Current Lua also supports proper single-character binary ops for BAND,BOR,BXOR and BNOT. Those would also simplify our code and reduce our token count. Plus they'd stop encouraging new programmers to do things like %128 when they mean &127, which is a bad habit.

So... zep, would it be painful to update your Lua library? I'd hope that, if it's stock anyway, it wouldn't be too bad...?

yeah not surprised, and it might be a recent addition. too lazy to check. :) It'd be cool for Pico-8 to fold in a newer interpreter at some point. I might be underestimating the amount of interpreter customizations, though.

Not sure what the backwards compatibility implications are. One thing I like about this ecosystem is that almost all of the uses of the platform are published to a central database with licensing terms that would allow a bulk automated test or at least a compilation pass. So while a change might be theoretically backwards incompatible, Lexaloffle can test to see what actually breaks and make a judgement call. (And of course we're still in alpha territory, so at least I personally would be comfortable with breaking some very old or obscure carts.)

It's alpha. We should all be ready for carts to break. I'm not saying it shouldn't be avoided if possible, but working on an alpha platform implies a willingness to rework your code as changes come in. It'd be different if we were in beta.