Re: Question about 4.1 optimization

[Edgar Toernig <froese@...>]

Roberto Ierusalimschy wrote:
> 
> We are building a new set of opcodes, so that luaV_execute will not
> be a stack machine. It will fix L->top at entrance, and then use all
> entries between base and L->top as `registers'.

It would be nice if you'ld allow some kind of variable number of slots
between the highest "register" and L->top (i.e. to save var args when
a table is not required or some other, run-time defined number of
objects).  But maybe that breaks your new design.

The interesting question is, whether functions calls will be build
up within the "registers" or at L->top ;-)

> All opcodes will have explicit operands. That will save lots of
> "getlocal" and "setlocal" opcodes, as operators will operate
> directly on the local.

Hmm... a 3 address machine could be really nice.  But I guess a lot
of work on the code generator, especially when trying to optimize
the creation of argument lists for function calls (I think a lot of
opcodes are just doing that).  Hmm... but 3 addresses for 16 bit
instructions would be a little bit difficult.  Only 2 addresses?
Or variable number of bytes?

> As getlocal is one of the most frequent opcodes, we expect that
> change to bring some performance improvment.

I guess something like "OP_MOVE src,dest" will be the most used one
afterwards ;-)

> That is, they will hang around for a while, until
> they are overwritten, or the function ends, or a garbage collection
> happens inside a function called by this one (when a function calls
> another one, L->top is "corrected"). Specifically, if the function
> calls "collectgarbage", all those arbitrary objects will be proper
> collected.

I see.  I was just too pessimistic ;-)  I think there could be some
bad conditions where objects will never be collected but trying to
find _reasonable_ examples is pretty difficult.  And the call to
"collectgarbage" will always clean up.

> [open calls] Such
> instructions are always immediately followed by an "appropriate"
> instruction that "uses" all those values (a return, another call,
> or a setlist).

Ok.  It looked so strange, live objects above L->top across opcode
boundaries...

> The above code
> creates a "safer" zone, so that any object which now are garbage but
> may look "alive" later is set to nil.

Uhh... I see.  Nasty situation.  I was already thinking about filling
the gap between the last result of a call and a.base+a.maxstacksize
with nil instead of just assigning to L->top.  But that will probably
ruin the whole L->top optimization.  Maybe this code just wants you
to tell that something's too tricky in that part of the L->top handling
;-)

> (Not very clear the explanation, is it?)

Hmm, IMHO pretty good.


Thanks, ET.