Re: question about upvalue bytecode encoding
- From: Francesco Abbate <francesco.bbt@xxxxxxxxx>
- To: luajit <luajit@xxxxxxxxxxxxx>
- Date: Thu, 27 Mar 2014 21:33:36 +0100
2014-03-26 0:19 GMT+01:00 Richard Hundt <richardhundt@xxxxxxxxx>:
> It's just PROTO_UV_LOCAL | PROTO_UV_IMMUTABLE vs PROTO_UV_LOCAL. During
> `bcemit_store` the upvalue gets a flag set which records that it's been
> written to, in which case you just have 0x8000, otherwise it's immutable. My
> guess is that LuaJIT optimizes cases where an upvalue is only read and not
> written to. I was just taking a shortcut by not including this optimization,
> but it should be easy enough to detect and add these cases.
Nice, now it is implemented with the following commit:
https://github.com/franko/luajit-lang-toolkit/commit/0a36a1f2d494b19e088f44da9fa910d89da341aa
I just use a "mutable" flag as you suggested and set it to true when a
variable is used in the left hand side of an assignment.
I've tested the change with a selection of test cases and the
generated bytecode matches the bytecode generated by luajit.
Otherwise, may be some people can be interested but I've juste merged
in the master branch of the luajit language toolkit
(https://github.com/franko/luajit-lang-toolkit) the topic branch that
implements the goto statements. The most difficult aspect was to
generate accurate UCLO instructions instead of JMP when a GOTO was
putting out of scope some local variables. For example the test:
https://github.com/franko/luajit-lang-toolkit/blob/master/tests/goto-markov-2.lua
require the generation of a mix of UCLO and JMP instructions according
to the target of the goto and the local variable declarations. The
language toolkit is now able to generate correctly the instructions
for all the possible cases and give error codes for invalid goto
statements.
Francesco
Other related posts:
