lua-users home
lua-l archive

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


On Mon, Jan 13, 2014 at 06:35:11PM -0800, Tim Hill wrote:
> 
>    On Jan 13, 2014, at 5:22 PM, Journeyer J. Joh
>    <[1]oosaprogrammer@gmail.com> wrote:
> 
>    Hi David Olofson,
>    Thank you!
>    Then Lua VM would be similar to the ones in JVM or .net or Dalvic.
>    Thank you very much.
>    Journeyer
> 
>    Yes and no.
> 
>    Java was originally a pure VM. The compiler emitted a pseudo machine
>    code ("bytecode") that was then interpreted at run time by a VM; no
>    native machine code was generated.
<snip>

But it was always intended to be JITd even before Sun published the
specification. Sun was doing JIT compilation before Java was created, and
that experience fed directly into the design of Java.

>    Unlike Java, the .Net model was designed as a JIT from day one.
<snip>

Yet both Java bytecode and the CIL use stack-based virtual machine models,
which is the precise thing you don't want to do if you want to make native
code compilation easier. Stack-based is what you use when you want things to
be simpler and more convenient for compilation and execution in software.

>    Lua uses an approach similar to the original Java VM (and others that
>    predate it all the way back to the P-System and others); the compiler
>    emits Lua "bytecode" (in the generic sense, it's nothing to do with
>    Java bytecode) and the Lua VM directly interprets that bytecode --
>    there is no JIT (unless you switch to the 3rd party LuaJIT compiler).
>    Generally, however, (imho) the Lua bytecode is more efficient than the
>    equivalent Java bytecode, resulting in a lower run-time performance
>    penalty than the original Java.
> 
>    So, Lua is nearest to the original Java, but better :)

Lua uses a register-based virtual machine architecture, which is one reason
why Lua is so ridiculously fast even in pure software.