lua-users home
lua-l archive

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


Hello,

----- Original Message -----
From: "Luiz Henrique de Figueiredo" <lhf@tecgraf.puc-rio.br>
To: <lua@bazar2.conectiva.com.br>
Sent: Thursday, October 23, 2003 8:21 AM
Subject: Re: Lua return


> >can you or Roberto explain how is the "calling" convention and what's
> >the params to RETURN (010,020)?
>
> Use the source , Luke! In this case, it's even commented!
...
    I already did (and always do :-).
...
> ...from lopcodes.h:
>
>   OP_CALL,/*      A B C   R(A), ... ,R(A+C-2) := R(A)(R(A+1), ...
,R(A+B-1)) */
>
> This means: call the function in register A, using B-1 args starting at
A+1,
> and store C-1 return values starting at A.
...
    First, Lua has a stack based  or register based vm?
    This is because here (and in the sources) you says "register", but in
lvm.c, luaV_execute, R(A) means an item on the stack, this is because I ask
you "what's the params to R...", below you answer me, with "... on the
stack", if A points to an index on the stack, A isn't a register, and Lua vm
is a stack based, right?
    Second, ok, OP_CALL comment ( from /* to */) is very self explanatory,
only reading it I know how the Earth was made by God ;-).
    What's "store C-1 return values starting at A"? Isn't this related with
OP_RETURN?

>
>   OP_RETURN,/*    A B     return R(A), ... ,R(A+B-2)      (see note)
*/
>
> This means: return B-1 values starting at A; if B is 0, return everything
> on the stack.
    Ok, but this I know, I want to know what *is* the params ( R(A), R(B),
... ) as you call "register", but... Sometimes is a stack item, other times
is point to a inst. in instruction pool, etc...

>
> >    Well, Why you guys don't make this?:
> >    When encounter a return (in source code), do:
> >    PUSH the values to the stack,
> >    PUSH the number of values to return,
> >    JUMP to the end of function, if necessary (if it's already at end),
>
> The code generated by this scheme has an extra instruction for each
return.
> The current scheme has at most a single extra instruction. Why worry about
> a harmless RETURN at the end??
> --lhf

    Nothing, only because it's strange, but when executing the cost is the
same, see luaV_execute, you will never need to expand the params of RETURN
(A..) as they don't exist (but perhaps the "PUSH the number of values to
return" is a LOADK inst?), and if the items to return is less then 256, you
can pack in the jump instruction field A. Well, your jump instruction isn't
like long_jump, for example, because it only modify the pc value and nothing
more, this isn't "extra cost", in my opinion.
    But, well, I am only making a suggestion.

PS: Someone in Brazil can help me make a tutorial in pt-br to Lua 5.X? If
yes, send me an e-mail (direct, not throught the list).

                                                    Thanx,


Leandro.