[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: Debug hook not called on "local" lines in some cases
- From: Paul K <paulclinger@...>
- Date: Wed, 30 Jan 2013 15:29:14 -0800
Thanks Dan and Liam for the explanation.
So this effectively means that "local a,b,c" and "local a; local b;
local c" are completely equivalent in terms of generated bytecode (as
one may expect) and "local a, b, c = 1" is a tad more efficient than
"local a, b, c = nil, 1" as it generates fewer commands.
I'll probably rely on debug.getinfo(1, "L").activelines to figure out
the list of actual lines.
Paul.
On Wed, Jan 30, 2013 at 2:10 PM, liam mail <liam.list@googlemail.com> wrote:
> On 30 January 2013 21:33, Paul K <paulclinger@yahoo.com> wrote:
>> Is this a feature or a bug?
>
> This is a feature. Lets just look at one implementation 5.2 for now.
> local a
> local b
> local c
> local d
> c = 1
>
> Produces only there instructions one of which is the default return.
> The first two being OP_LOADNIL which assigns nil to the first four
> stack slots and the OP_LOADK which assigns the constant to slot 2(zero
> indexed)
>
>
> local a
> local b = 1 --<-- added assignment
> local c
> local d
> c = 1
> This will have five instructions, OP_LOADNIL to the first slot(a),
> OP_LOADK to the second slot(b), OP_LOADNIL to load nil to the third
> and four slots (c and d), OP_LOADK loading the constant into slot 2(c)
> and the final OP_RETURN.
>
>
> Now 5.1 bytecode is slightly different in that the OP_LOADK's are
> optimised out for locals at the beginning of a scope so the first
> snippet I have show will only have two instructions; one to load a
> constant and the default return.
>
> So it is a mixture of an optimisations and OP_LOADNIL loading values
> to more than one slot.
>
> --Liam
>