[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: Lua return
- From: "Leandro Candido" <enclle@...>
- Date: Thu, 23 Oct 2003 13:22:01 -0200
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.