lua-users home
lua-l archive

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


Eike Decker wrote:
> But maybe I am wrong here - actually I wonder if Mike has stumbled upon this
> issue when implementing LuaJIT and what his opinion on this matter would be.

It's very important to not overspecify language semantics in areas
where there's no pressing need. Because every little piece of
unspecified behavior provides an extra degree of freedom for
language implementations and the further evolution of the
language semantics.

Imperative languages usually have implicit sequence points between
statements. This means there's already a perfectly sensible way to
get a defined evaluation order: split it up into different
statements. Overconstraining evaluation order of sub-expressions
of n-ary functions or operators neither helps the user (hard to
explain) nor the implementation (may be hard to guarantee).

Modern CPUs are super-scalar, which is just another word for
parallel execution on the smallest scale. Some data-flow dependent
instructions inhibit out-of-order execution and can have a
significant impact on the number of retired instructions/cycle.
Allowing a compiler to freely reorder expressions often improves
code quality which in turn improves throughput.

[
Case in point about over-specification: the first JavaScript spec
was derived from Netscape's JavaScript implementation. It codified
the exact behavior of this implementation with all of its quirky
corners and even a lot of nonsensical or coincidental semantics.
Every JavaScript interpreter or compiler up to today has to
implement all of this for strict conformance.

The JavaScript JIT compilers that have been popping up in the last
two years suffer badly in some cases. E.g. all the corner cases of
double->int/uint conversions, having unsigned types in the
language in general, the string vs. integer dichotomy in array
indexing, the strange scoping rules, handling of 'this' and so on ...

Bad things can happen even when you forget to mention undefined
behavior in the  spec. E.g. early Netscape used insertion-ordered
associative tables, so a lot of user code started to depend on it.
It's not required by the standard, but every implementation needs
to simulate this and pay for the overhead. Writing a JavaScript
implementation from scratch which works equally well with all of
the JavaScript code out there is a true nightmare.
]

--Mike