Re: Portability of Lua

[William Ahern <william@...>]

On Wed, May 01, 2013 at 12:00:39AM -0700, Tim Hill wrote:
<snip>
<snip>
> > That's an odd argument to make. No general purpose language makes that
> > guarantee. Runtime limits are nearly impossible to standardize, although C
> > makes a passable attempt. Anyhow, on systems with pageable virtual memory,
> > even a block of memory already allocated can stall the whole execution
> > context. In any event C, just like Java or C#, is defined in terms of an
> > abstract "virtual" machine.
> 
> Also, C is NOT defined in terms of a VM (real or virtual), unlike Java, which is why there is far more variability in C than Java. Java has its faults (legion), but in general Java code (and, to a lesser extent, C#) is more portable than C for this reason. Spend any time looking at the Lua header files to see what incredible lengths Roberto's team had to jump through to make Lua as portable as it is, they certainly did NOT just "write it in ANSI C".

I may have misspoke, but to quote the standard:

	5.1.2.3 Program execution

	The semantic descriptions in this International Standard describe
	the behavior of an abstract machine in which issues of optimization
	are irrelevant.

An implementation of such an abstract machine would be a virtual machine,
but I'm not sure the distinction actually matters. What really separates C
from Java are the parameters Java specifies for the machine, which are much
more rigid and which often require emulation when they're unsupported by the
hardware.

Some platforms must emulate C semantics in software, too, but because C's
parameters are more flexible so this doesn't happen nearly as often.