Re: [ANN] Lua 5.4.0 ... struct with variable size array ... C90 support

[William Ahern <william@...>]

On Wed, May 20, 2020 at 12:19:39PM -0500, Coda Highland wrote:
<snip>
> As was implied, the description of a virtual platform model is exactly what
> Java set out to do. Java can and does have the ability to run on dirt-cheap
> processors that consume very little power. That was, in fact, one of Java's
> design goals, and if your cell phone has a SIM card in it then you're using
> Java in exactly that context. It's not the language itself that's the
> problem.

The design of Java and the JVM architecture is problematic. Most well-known
is the lack of value types. More pertinent to Lua, it has been argued that a
pure stack machine architecture is difficult to make performant on common
hardware. This argument was made by the designers of the Dis VM in their
paper, "The design of the Inferno virtual machine":

  A JIT for an SM is forced to do most of the work of register allocation in
  the JIT itself. Because the types of stack cells change as the program
  executes, the JIT must track their types as it compiles. In an MM,
  however, the architecture maps well to native instructions. This produces
  a continuum of register allocation strategies from none, to simple mapping
  of known cells to registers, to flow-based register allocation. Most of
  the work of any of these strategies can be done in the language-to-VM
  compiler. It can generate code for an infinite-register machine, and the
  JIT can then allocate as many as are available in the native architecture.
  Again, this distribution of work keeps the JIT simple.

  http://www.vitanuova.com/inferno/papers/hotchips.html

That paper was cited in "The Implementation of Lua 5.0" where its explained,

  Register-based code avoids several "push" and "pop" instructions that
  stackbased code needs to move values around the stack. Those instructions
  are particularly expensive in Lua, because they involve the copy of a
  tagged value, as discussed in Section 3. So, the register architecture
  both avoids excessive copying of values and reduces the total number of
  instructions per function. Davis et al. [6] argue in defense of
  register-based virtual machines and provide hard data on the improvement
  of Java bytecode. Some authors also defend registerbased virtual machines
  based on their suitability for on-the-fly compilation (see [24], for
  instance).

  https://www.lua.org/doc/jucs05.pdf

Citation 24 is to the aforementioned paper by Phil Winterbottom and Rob
Pike. I've always assumed that Lua's VM architecture was partly inspired by
the Dis VM paper, but maybe it was just coincidence--or rather, great minds
thinking alike.

WebAssembly dumped their AST paradigm and switched to stack machine
semantics because it was believed it would make it easier to implement
secure semantics and safe implementations using known techniques, and it fit
well with their structured control flow model and their presumption
compilers would rely on the relooper algorithm. (The AST and stack machine
were equivalent, anyhow.) But there existed contemporareous and subsequent
research that showed register machine-based JIT architectures with goto
could be implemented just as easily (if not more easily) and just as safely,
with the already well-establised performance benefits. And compilers like
LLVM and V8 are already capable of more sophisticated, yet just as safe,
transformations that could theoretically take advantage of a more liberal VM
architecture. Alas, WebAssembly is now stuck with its stack machine
semantics, which causes alot of problems supporting low-level constructs for
exceptions, coroutines, etc. See, e.g.,
http://troubles.md/posts/why-do-we-need-the-relooper-algorithm-again/ It

WebAssembly was crippled the moment it was finalized. They missed the
opportunity--the switch from the AST to stack machine model--to add some
critical semantics for it to be a viable, performant machine target for some
of the nicer modern languages. They stuck to the stack machine model because
they believed the propaganda--that stack machines were necessary for their
security model, and equivalent in terms of ease of language targeting and
performance optimizations.