* Change duk_bool_to to duk_small_uint_t from duk_small_int_t. This may
cause some sign warnings in calling code.
* Reject attempt to unpack an array-like value whose length is 2G or over;
previously was not checked explicitly, and the length was cast to duk_idx_t
with a sign change and the unpack would then later fail. Now it fails with
a clean RangeError.
* Add wrap check for Node.js Buffer.concat().
* API DUK_TYPE_xxx, DUK_TYPE_MASK_xxx, flag constants etc are now unsigned.
* Allow duplicates keys, even in strict mode (ES6).
* Add identifier reference shorthand: { Math }.
* Add method definition shorthand: { foo(a,b) { return a + b; } }.
* Eval/program code no longer has the CONSTRUCTABLE flag which was
previously set. Calling an eval/program function as a constructor
makes no sense and wasn't really supported previously. This change
has no compliance impact because eval/program code doesn't exist as
an unexecuted function in Ecmascript.
* Eval/program code no longer has a NAMEBINDING flag which was previously
set. The revised behavior is cleaner because eval/program code must
not have a name binding. However, the flag is only consulted if NEWENV
is also set, and NEWENV is never set for eval/program code. So this
change has no other effect other than affecting dumped bytecode.
Previously _Varmap was kept if any slow path accesses were made. Improve this
behavior so that, in the absence of eval() etc, safe slow path accesses are
allowed while still dropping the _Varmap. A safe slow path access is one that
doesn't match any of the statically declared variables in the function so that
(again assuming no new variables are declared by e.g. eval()) the varmap won't
be needed at runtime.
Allow dropping of _Formals even in presence of eval() or a potentially
dangerous slow path access if _Formals is empty *and* _Formals.length matches
nargs so that .length computation works out even without _Formals.
Also reduce initial bytecode allocation from 2kB to 256 bytes when
DUK_USE_PREFER_SIZE is defined (in absence of a more specific define).
Change dispatch to use an 8-bit main opcode instead of a 6-bit one.
This removes the need for "EXTRA" opcodes and a secondary switch
clause in the executor dispatch loop.
The new opcode layout uses four 8-bit fields: opcode, A, B, C. The
previous reg/const concept which used 9-bit B and C fields, with the
top bit reserved to denote reg vs const, is now implemented by using
four consecutive opcode slots and moving the B and C reg/const flags
into the opcode. For example:
ADD_RR reg(A) <- reg(B) + reg(C)
ADD_CR reg(A) <- const(B) + reg(C)
ADD_RC reg(A) <- reg(B) + const(C)
ADD_CC reg(A) <- const(B) + const(C)
From a footprint standpoint this allows the executor to remain roughly
the same size: four dispatched opcodes (each a function pointer in a
compiled jump table) point to the same case clause handler, which does
the reg/const decision based on an instruction bit test as before.
However, when performance is more important than footprint, each reg/const
case can be handled separately in the executor so that there's no longer
a reg/const check when the opcode executes.
Note that not all opcodes require a reg/const qualifier, so that opcode
space is effectively increased even if reg/const opcodes consume multiple
entries from the opcode table.
Other minor changes:
* Optimize behavior of several opcodes to e.g. avoid unnecessary support
for shuffling/indirection when wider register arguments are now
available.
Improve readability by doing the following renames:
* duk_hcompiledfunction -> duk_hcompfunc
* duk_hnativefunction -> duk_hnatfunc
* duk_hbufferobject -> duk_hbufobj
Corresponding renames for all caps defines.