lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index] 

在 2016/3/22 9:04, Scott Morgan 写道:

On 21/03/16 21:07, René Rebe wrote:

On Mar 21, 2016, at 17:12, Coda Highland <chighland@gmail.com> wrote:

On Mon, Mar 21, 2016 at 9:10 AM, Scott Morgan <blumf@blueyonder.co.uk> wrote:

On 21/03/16 15:59, Dirk Laurie wrote:

2016-03-21 16:32 GMT+02:00 Wangbo <wangbo.red@gmail.com>:

I have simple Lua code, why have two RETURN opcode for foo function after i
check compile code.

6 [4] RETURN   1 2
7 [5] RETURN   0 1

Checking all code paths to make sure that the `end` statement
cannot be reached would make the compiler more complicated.

Is this an overhead of supporting gotos?

Considering this is bytecode and everything from loops to conditionals
are implemented as jumps? You could say that. But it's not
specifically tied to the "goto" language feature; it would still be
relevant even if you couldn't use "goto" in Lua code.

IIRC older Lua versions indeed already simply did this too.
At least I remember seeing this in 5.1 which did not yet had gotos, …

Interesting. In what situations (i.e. what kind of source code) does
this become an issue that the extra return is needed? Error handling?

Scott




it is there because it simplifies the code generator: it simply issues a RETURN opcode
when according to 'end' keyword which matches the 'function' keyword. and it is no harm
if the code has explicit return statement.


it is not an __extra__ RETURN opcode.  consider the two functions:


function foo () return end
function bar () end


if the program has a explicit return statement just before the end of the function,
then the auto generated RETURN opcode has no effect. it will not execute anyway.
in case the function does not have a explicit return statement right before the end of
function, then this implicit RETURN code will do the job.


--
the nerdy Peng / 书呆彭 / Sent from Thunderbird