 |
lua-l archive |
|
|
||
|
KHMan wrote:
If for some reason you change the bytecode order, or add new bytecodes, compiled scripts will ONLY execute on a VM with the matching Op Codes/Op Codes order. It's a well known thing, but if it's supposed to be a portable optimizer then it would probably be best to have it output it's optimized code in Lua source, not Lua bytecode/opcodes.Olivier Hamel wrote:David Manura wrote:I stand corrected. :) Thanks for the info, I'd've thought it be the other way around really. I'm not too sure having it emit bytecode is a good idea since it breaks the second you move the byte code around.On Fri, May 15, 2009 at 11:25 AM, Philippe Lhoste wrote:On 15/05/2009 14:14, Olivier Hamel wrote:[snip] Metalua resorts instead to writing its own bytecode generator. [1] http://lua-users.org/wiki/OptimisationCodingTips [2] http://en.wikipedia.org/wiki/Strength_reduction [3] http://gcc.gnu.org/onlinedocs/cpp/Line-Control.htmlNot all optimizations can be done using source-to-source translation. We might want to bypass the Lua locals allocator, for example. Good or bad (or complications galore) I dunno, but it's a cute academic exercise. Still, a user might want the result in source form, so I think there is a place for either kinds of output.When I read this: "since it breaks the second you move the byte code around." It's so vague, what does it mean anyway, exactly?