Disable coroutine support pretty roughly (saves around 2kB footprint):
- Duktape.Thread() constructor throws.
- Duktape.Thread methods yield(), resume(), current() throw.
- Bytecode executor doesn't handle yield/resume.
You can still create Duktape threads from the C API and make calls into
the threads. But the threads can't launch/resume new threads.
* Rename fastint macros so that e.g. DUK_SET_FASTINT_U32() becomes simply
DUK_SET_U32(). This makes more sense because the macros are also enabled
without fastint support. Right now the macros will just cast e.g. a uint32
to a double and set it to the duk_tval, but that operation can be optimized
even when fastints are not present.
These don't play well with the API currently: the Duktape specific error
codes don't have Ecmascript Error class counterparts so they don't get
represented usefully as Ecmascript objects (e.g. AllocError is a plain
Error from Ecmascript point of view).
There's no real need for Duktape specific error code. Some of the codes
had become unused; a couple were used but Ecmascript standard types can
be used instead.
Also minor error message tweaking.
Instead of decoding a field (say A) and then computing DUK__REGP which
involves further shifting of the value, add macros such as DUK__REGP_A(ins)
which operate directly on the 32-bit 'ins' and use a single shift+mask to
get the byte offset (rather than element offset) for the target reg/const.
Technically the compiler should be able to do this, but in practice at
least gcc -O2 won't.