Use a 'consts' base pointer in executor stack frame instead of looking up the
consts base through 'fun' for every const access. This is marginally faster
and has a slightly smaller code footprint for -O2.
This leads to slightly faster lookups because the constants base does not
need to be looked up from the current function. Code footprint is also
decreased by around 0.5kB which is nice.
Change bytecode executor to dispatch using a direct bytecode pointer held in
thr->curr_pc and activations to store their curr_pc as a direct bytecode
pointer. The thr->curr_pc pointer is a cached copy of the topmost
activation's act->curr_pc. Dispatching using the cached copy is faster than
dispatching through act->curr_pc, probably because there's less register
pressure when using thr for the access.
The change improves bytecode raw dispatch performance by roughly 20%.
The downside of the change is that the cached thr->curr_pc needs to be
synced back in several code paths which is error prone.
See GH-265.
The document is based on early design notes for Duktape 1.0 and is not
entirely up-to-date or very clean, but it still provides a reasonable
overview of how the compiler works.
Fix debugger GetCallStack line number semantics so that for value stack
entries below the topmost entry PC/line will reflect the opcode in
progress rather than the opcode following that (GH-281).
Remove DUK_OPT_DEEP_C_STACK/DUK_USE_DEEP_C_STACK, use deep stacks by default
on all targets, add explicit config options for individual C stack depths so
that they can be tuned from duk_config.h if necessary (which has been the case
for RegExps for instance).
The new Date provider snippet location is after duk_custom.h and other
overrides, so that e.g. user custom header can define
DUK_USE_DATE_NOW_GETTIMEOFDAY even if the platform detection does not.