duktape

Commit Graph

Author	SHA1	Message	Date
Sami Vaarala	5ed6bb980b	Add initial, minimal ES6 Symbol support * Strings with 0xFF byte prefix are considered special symbols: they have typeof "symbol" but still mostly behave as strings (e.g. allow ToString) so that existing code dealing with internal keys, especially inside Duktape, can work with fewer changes. * Strings with 0x80 byte prefix are global symbols, e.g. Symbol.for('foo') creates the byte representatio: 0x80 "foo" * Strings with 0x81 byte prefix are unique symbols; the 0x81 byte is followed by the Symbol description, and an internal string component ensuring uniqueness is separated by a 0xFF byte (which can never appear anywhere in an extended UTF-8 string). The unique suffix is up to Duktape internals, currently two 32-bit counters are used. For example: 0x81 "mySymbol" 0xFF "0-17". * Well-known symbols use the 0x81 prefix but lack a unique suffix, so their format is 0x81 <description> 0xFF. * ES6 distinguishes between an undefined symbol description and an empty string symbol description. This distinction is not currently visible via Ecmascript bindings but may be visible in the future. Append an extra 0xFF to the unique suffix when the description is undefined, i.e. 0x81 0xFF <unique suffix> 0xFF.	8 years ago
Sami Vaarala	39ecb8b7eb	Source fixes for #ifdef and #ifndef convention	8 years ago
Sami Vaarala	33afc2c102	Explicit lexenv/varenv in duk_hcompfunc	9 years ago
Sami Vaarala	96d301b3cb	Rename src/ to src-input/ to match dist With this change the directory naming in the main repo and dist is the same.	8 years ago
Sami Vaarala	75c57ad6f4	Rework executor to use a single level dispatch 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.	8 years ago
Sami Vaarala	d84c1ce43e	Finalize buffer behavior when no bufobj support * Plain buffers still inherit from ArrayBuffer.prototype. * Plain buffers won't object coerce, so Object(plainBuffer) fails. * All buffer object related methods throw an error; their function bodies are essentially empty. Note that this includes bindings such as String.fromBuffer(), ArrayBuffer.allocPlain(), ArrayBuffer.plainOf(), and so on. In essence, you can index plain buffers in Ecmascript but the buffer values must be created via the C API. * Duktape custom bindings like Duktape.dec('hex', 'deadbeef') still work and produce plain buffers.	8 years ago
Sami Vaarala	173f3c75e5	Simplify call handling opcodes a bit * Remove CSPROP(I) opcode. CSPROP usually leads to three opcodes, e.g. LDREG + LDCONST + CSPROP. Direct loads for 'base[key]' and 'base' has the same effect with one opcode shorter bytecode and no need for a separate CSPROP opcode. * Remove CSREGI (indirect) opcode, simplify CSREG opcode a bit. Extend CSREG base register argument to be wider (BC) so that shuffling is not needed in practice. * Remove CSVARI (indirect) opcode and handle its equivalent by using explicit shuffling in the compiler. This removes one opcode, and indirect target check from CSVAR. * Remove NEWI and extend base register argument of NEW to be wider (BC) so that shuffling is not needed in practice. * Remove CALLI, and split CALL into CALL, TAILCALL, and EVALCALL. This eliminates the flags field (A) and allows the base register to be wider (BC), eliminating the need for shuffling in practice. * Maximum argument count to constructor and ordinary calls drops from 511 to 255 with this change.	9 years ago
Sami Vaarala	5a92ca85ac	Add duk_harray internal type Also rename "BOUND" to "BOUNDFUNC" in internal flags for consistency with "COMPFUNC" and "NATIVEFUNC".	9 years ago
Sami Vaarala	a804a2a630	Rename internal struct/define names 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.	9 years ago
Sami Vaarala	f64f215e1d	Remove manual #undefs from source files These are no longer needed because combine_src.py adds them automatically.	9 years ago
Sami Vaarala	2d19e7cdef	Improve heap object debug printout * Add prototype pointer even when not following pointers. * Include own pointer as __heapptr.	9 years ago
Sami Vaarala	eb8201293d	Add 'magic' to debug dump of nativefunctions	9 years ago
Sami Vaarala	c32f41407b	Changes for ROM string/object support	9 years ago
Sami Vaarala	efc52c8e8d	Separate (marker) unused tag Reorder tags to accommodate a separate 'unused' tag so that 'undefined' can become a single tag write (instead of tag + value like booleans). This is good because 'undefined' values are involved in e.g. value stack resizes and are performance relevant. Also reorder tags so that "is heap allocated" check can be a single bit test instead of a comparison when using non-packed duk_tval. This makes every DECREF potentially faster because an "is heap allocated" test appears in every DECREF. Because "unused" is not intended to appear anywhere in actual use (e.g. as a value stack value, as a property value, etc), "unused" values will fall into the default clause of DUK_TAG_xxx switch case statements. Add an assert to every such default clause that the value is not intended to be "unused". Remove duk_push_unused() as it should no longer be used. It was only used by the debugger protocol; refuse an inbound "unused" value in the debugger. This is not breaking compatibility because there was no legitimate usage for the debug client sending requests with "unused" values.	9 years ago
Sami Vaarala	4ef206dbb5	Add support for external buffers An external buffer is similar to a dynamic buffer but the external data pointer is managed by user code rather than Duktape, and may point to an arbitrary address. For example, user can build an external buffer which points to a framebuffer and operate on that framebuffer from Ecmascript code via the buffer.	10 years ago
Sami Vaarala	fb17fd0184	Remove dynamic buffer spare	9 years ago
Sami Vaarala	92d33fd550	Implement Node.js Buffer and TypedArray support	10 years ago
Sami Vaarala	0f0fe6e4f4	Change to explicit fastint downgrade model Midcommit: Feature detection typo fix (harmless). Add self test for known double-to-int64 issue. Add DUK_INLINE and DUK_ALWAYS_INLINE.	10 years ago
Sami Vaarala	c281a7e8a0	Rework pre/post inc/dec in compiler and executor Pre/post inc/dec are an important fast path for fastints. Reimplement these operations as atomic opcodes so that fast pathing is easier. Opcodes emitted for typical loop constructs are also reduced by the change. Several opcodes were moved to extraops to make space for the 12 pre/post inc/dec reg/var/prop variants, and the compiler was changed to support two-argument (dest, dest, src) extraop arithmetic for its ispec/ivalue. Example of bytecode change, in Duktape 1.1.0: function foo() { var x = 10; print(x++, x++, x--, x--, x--); print(x); } BC 0000: LDINT 0, 10, 256 ; 0x80028003 op=3 (LDINT) a=0 b=10 c=256 BC 0001: CSVAR 1, 256, 0 ; 0x00400052 op=18 (CSVAR) a=1 b=256 c=0 BC 0002: LDREG 3, 0, 0 ; 0x000000c0 op=0 (LDREG) a=3 b=0 c=0 BC 0003: TONUM 3, 3 ; 0x0180c2fe op=62 (EXTRA) a=11 b=3 c=3 BC 0004: INC 0, 3 ; 0x0180067e op=62 (EXTRA) a=25 b=0 c=3 BC 0005: LDREG 4, 0, 0 ; 0x00000100 op=0 (LDREG) a=4 b=0 c=0 BC 0006: TONUM 4, 4 ; 0x020102fe op=62 (EXTRA) a=11 b=4 c=4 BC 0007: INC 0, 4 ; 0x0200067e op=62 (EXTRA) a=25 b=0 c=4 BC 0008: LDREG 5, 0, 0 ; 0x00000140 op=0 (LDREG) a=5 b=0 c=0 BC 0009: TONUM 5, 5 ; 0x028142fe op=62 (EXTRA) a=11 b=5 c=5 BC 0010: DEC 0, 5 ; 0x028006be op=62 (EXTRA) a=26 b=0 c=5 BC 0011: LDREG 6, 0, 0 ; 0x00000180 op=0 (LDREG) a=6 b=0 c=0 BC 0012: TONUM 6, 6 ; 0x030182fe op=62 (EXTRA) a=11 b=6 c=6 BC 0013: DEC 0, 6 ; 0x030006be op=62 (EXTRA) a=26 b=0 c=6 BC 0014: LDREG 7, 0, 0 ; 0x000001c0 op=0 (LDREG) a=7 b=0 c=0 BC 0015: TONUM 7, 7 ; 0x0381c2fe op=62 (EXTRA) a=11 b=7 c=7 BC 0016: DEC 0, 7 ; 0x038006be op=62 (EXTRA) a=26 b=0 c=7 BC 0017: CALL 0, 1, 5 ; 0x02804034 op=52 (CALL) a=0 b=1 c=5 BC 0018: CSVAR 1, 256, 0 ; 0x00400052 op=18 (CSVAR) a=1 b=256 c=0 BC 0019: LDREG 3, 0, 0 ; 0x000000c0 op=0 (LDREG) a=3 b=0 c=0 BC 0020: CALL 0, 1, 1 ; 0x00804034 op=52 (CALL) a=0 b=1 c=1 BC 0021: RETURN 1, 0, 0 ; 0x00000073 op=51 (RETURN) a=1 b=0 c=0 After this commit: function foo() { var x = 10; print(x++, x++, x--, x--, x--); print(x); } BC 0000: LDINT 0, 10, 256 ; 0x80028003 op=3 (LDINT) a=0 b=10 c=256 BC 0001: CSVAR 1, 256, 0 ; 0x00400052 op=18 (CSVAR) a=1 b=256 c=0 BC 0002: POSTINC 3, 0, 0 ; 0x000000f9 op=57 (POSTINC) a=3 b=0 c=0 BC 0003: POSTINC 4, 0, 0 ; 0x00000139 op=57 (POSTINC) a=4 b=0 c=0 BC 0004: POSTDEC 5, 0, 0 ; 0x0000017c op=60 (POSTDEC) a=5 b=0 c=0 BC 0005: POSTDEC 6, 0, 0 ; 0x000001bc op=60 (POSTDEC) a=6 b=0 c=0 BC 0006: POSTDEC 7, 0, 0 ; 0x000001fc op=60 (POSTDEC) a=7 b=0 c=0 BC 0007: CALL 0, 1, 5 ; 0x02804030 op=48 (CALL) a=0 b=1 c=5 BC 0008: CSVAR 1, 256, 0 ; 0x00400052 op=18 (CSVAR) a=1 b=256 c=0 BC 0009: LDREG 3, 0, 0 ; 0x000000c0 op=0 (LDREG) a=3 b=0 c=0 BC 0010: CALL 0, 1, 1 ; 0x00804030 op=48 (CALL) a=0 b=1 c=1 BC 0011: RETURN 1, 0, 0 ; 0x0000006f op=47 (RETURN) a=1 b=0 c=0 For an empty for-loop, in Duktape 1.1.0: function foo() { for (var i = 0; i < 1000; i++) {} } BC 0000: LABEL 0, 0, 0 ; 0x00000036 op=54 (LABEL) a=0 b=0 c=0 BC 0001: JUMP 11 (to pc+12) ; 0x800002f2 op=50 (JUMP) a=11 b=0 c=256 BC 0002: JUMP 5 (to pc+6) ; 0x80000172 op=50 (JUMP) a=5 b=0 c=256 BC 0003: LDINT 0, 0, 256 ; 0x80000003 op=3 (LDINT) a=0 b=0 c=256 BC 0004: LT 1, 0, 256 ; 0x8000006d op=45 (LT) a=1 b=0 c=256 BC 0005: IF 0, 1, 0 ; 0x0000402f op=47 (IF) a=0 b=1 c=0 BC 0006: JUMP 1 (to pc+2) ; 0x80000072 op=50 (JUMP) a=1 b=0 c=256 BC 0007: JUMP 5 (to pc+6) ; 0x80000172 op=50 (JUMP) a=5 b=0 c=256 BC 0008: LDREG 1, 0, 0 ; 0x00000040 op=0 (LDREG) a=1 b=0 c=0 BC 0009: TONUM 1, 1 ; 0x008042fe op=62 (EXTRA) a=11 b=1 c=1 BC 0010: INC 0, 1 ; 0x0080067e op=62 (EXTRA) a=25 b=0 c=1 BC 0011: JUMP -8 (to pc-7) ; 0x7ffffe32 op=50 (JUMP) a=248 b=511 c=255 BC 0012: JUMP -5 (to pc-4) ; 0x7ffffef2 op=50 (JUMP) a=251 b=511 c=255 BC 0013: ENDLABEL 0, 0, 0 ; 0x00000037 op=55 (ENDLABEL) a=0 b=0 c=0 BC 0014: RETURN 1, 0, 0 ; 0x00000073 op=51 (RETURN) a=1 b=0 c=0 After this commit: function foo() { for (var i = 0; i < 1000; i++) {} } BC 0000: LABEL 0, 0 ; 0x0000083f op=63 (EXTRA) a=32 b=0 c=0 BC 0001: JUMP 9 (to pc+10) ; 0x8000026e op=46 (JUMP) a=9 b=0 c=256 BC 0002: JUMP 5 (to pc+6) ; 0x8000016e op=46 (JUMP) a=5 b=0 c=256 BC 0003: LDINT 0, 0, 256 ; 0x80000003 op=3 (LDINT) a=0 b=0 c=256 BC 0004: LT 1, 0, 256 ; 0x8000006b op=43 (LT) a=1 b=0 c=256 BC 0005: IF 0, 1, 0 ; 0x0000402d op=45 (IF) a=0 b=1 c=0 BC 0006: JUMP 1 (to pc+2) ; 0x8000006e op=46 (JUMP) a=1 b=0 c=256 BC 0007: JUMP 3 (to pc+4) ; 0x800000ee op=46 (JUMP) a=3 b=0 c=256 BC 0008: POSTINC 1, 0, 0 ; 0x00000079 op=57 (POSTINC) a=1 b=0 c=0 BC 0009: JUMP -6 (to pc-5) ; 0x7ffffeae op=46 (JUMP) a=250 b=511 c=255 BC 0010: JUMP -3 (to pc-2) ; 0x7fffff6e op=46 (JUMP) a=253 b=511 c=255 BC 0011: ENDLABEL 0, 0 ; 0x0000087f op=63 (EXTRA) a=33 b=0 c=0 BC 0012: RETURN 1, 0, 0 ; 0x0000006f op=47 (RETURN) a=1 b=0 c=0	10 years ago
Sami Vaarala	a613ac21c2	Midcommit for fastint support Remove support for 'full tval' init. It was never enabled, and there was no 'full tval' support for non-packed duk_tval anyway. Add fastint marker to Duktape.env.	10 years ago
Sami Vaarala	5c22523ebf	Add debugger support to core engine	10 years ago
Sami Vaarala	36494812ed	ENC16/DEC16/EXTSTR udata changes Also remove mostly unused old debug code. Debug code doesn't have access to 'heap' so it cannot decode pointers. Cause an #error for now if both debug prints and pointer compression are enabled at the same time. Remove duk_debug_hobject.c from make and dist. It was out of date and not used in practice anymore.	10 years ago
Sami Vaarala	ec62b01018	Non-leading tab fixes	10 years ago
Sami Vaarala	4586688185	Add some missing "const" specifiers for strings	10 years ago
Sami Vaarala	530f6e7ff7	16-bit fields and heap pointer compression work Memory optimization work for very low memory devices (96 to 256kB system RAM). Overall changes are: - 16-bit fields for various internal structures to reduce their size - Heap pointer compression to reduce pointer size to 16 bits When DUK_OPT_LIGHTFUNC_BUILTINS and the new low memory options are enabled, Duktape initial heap memory usage is about 23kB (compared to baseline of about 45kB) on x86. Unless low memory feature options are enabled, there should be no visible changes to Duktape behavior. More detailed changes: - 16-bit changes for duk_heaphdr: pointer compression, refcount - 16-bit changes for duk_hstring: hash, blen, and clen can all be 16 bits, use 0xFFFF as string byte length limit (call sites ensure this limit is never exceeded) - 16-bit changes for duk_hbuffer, use 0xFFFF as buffer length limit - 16-bit fields for hobject size (entry part, array part), drop hash part since it's not usually needed for extremely low memory environments - 16-bit changes for duk_hcompiledfunction - Heap pointer packing for stringtable - Heap pointer packing for 'strs' built-in strings list (saves around 600 to 700 bytes but may not be a good tradeoff because call site size will increase) Other changes: - Heaphdr NULL init fix. The original macros were broken: the double/single linked macro variants were the wrong way around. Now sets through macro to work properly with compressed pointers. - Rename duk_hbuffer CURR_DATA_PTR -> DATA_PTR to reduce macro length (previous name was tediously long) - Rename buffer "usable_size" to "alloc_size" throughout as they have been the same for a while now (they used to differ when buffer had an extra NUL). - Add memory optimization markers to Duktape.env (pointer compression and individual 16-bit field options) - Rename a few internal fields for clarity: duk_hobject 'p' to 'props', heap->st to heap->strtable - Add a safety check for buffer alloc size (should not be triggered but prevents wrapping if call sites don't properly check for sizes) - Other minor cleanups	10 years ago
Sami Vaarala	5e56112176	Second round of lightfunc support improvements * Fix outstanding FIXME issues for lightfunc semantics. * Improve API and Ecmascript testcases to match. * Clarify lightfunc limitations, e.g. finalizer limitations. * Guide and API documentation changes for lightfuncs. * Fix compile warning: duk_str_not_object unused.	10 years ago
Sami Vaarala	fef0870107	First round of lightfunc changes A lot of changes to add preliminary lightfunc support: * Add LIGHTFUNC tagged type to duk_tval.h and API. * Internal changes for preliminary to support lightfuncs in call handling and other operations (FIXMEs left in obvious places where support is still missing after this commit) * Preliminary Ecmascript and API testcases for lightfuncs Detailed notes: * Because magic is signed, reading it back involves sign extension which is quite verbose to do in C. Use macros for reading the magic value and other bit fields encoded in the flags. * Function.prototype.bind(): the 'length' property of a bound function now comes out wrong. We could simply look up the virtual 'length' property even if h_target is NULL: no extra code and binding is relatively rare in hot paths. Rewrite more cleanly in any case. * The use flag DUK_USE_LIGHTFUNC_BUILTINS controls the forced lightfunc conversion of built-ins. This results in non-compliant built-ins but significant memory savings in very memory poor environments. * Reject eval(), Thread.yield/resume as lightfuncs. These functions have current assertions that they must be called as fully fledged functions. * Lightfuncs are serialized like ordinary functions for JSON, JX, and JC by this diff. * Add 'magic' to activation for lightfuncs. It will be needed for lightweight functions: we don't have the duk_tval related to the lightfunc, so we must copy the magic value to the activation when a call is made. * When lightfuncs are used as property lookup base values, continue property lookup from the Function.prototype object. This is necessary to allow e.g. ``func.call()`` and ``func.apply()`` to be used. * Call handling had to be reworked for lightfuncs, especially how bound function chains are handled. This is a relatively large change but is necessary to support lightweight functions properly in bound function resolution. The current solution is not ideal. The bytecode executor will first try an ecma-to-ecma call setup which resolves the bound function chain first. If the final, unbound function is not viable (a native function) the call setup returns with an error code. The caller will then perform a normal call. Although bound function resolution has already been done, the normal call handling code will re-do it (and detect there is nothing to do). This situation could be avoided by decoupling bound function handling and effective this binding computation from the actual call setup. The caller could then to do this prestep first, and only then decide whether to use an ecma-to-ecma call or an ordinary heavyweight call. Remove duk__find_nonbound_function as unused. * Use indirect magic to allow LIGHTFUNCs for Date. Most of the built-in functions not directly eligible as lightfuncs are the Date built-in methods, whose magic values contain too much information to fit into the 8-bit magic of a LIGHTFUNC value. To work around this, add an array (duk__date_magics[]) containing the actual control flags needed by the built-ins, and make the Date built-in magic value an index into this table. With this change Date built-ins are successfully converted to lightfuncs. Testcase fixes: - Whitespace fixes - Print error for indirect eval error to make diagnosis easier - Fix error string to match errmsg updated in this branch	11 years ago
Sami Vaarala	0c20b43095	Add missing 'const' attribute for a few strings These missing 'const' attributes broke C++ debug build.	10 years ago
Sami Vaarala	2ef85f296e	Remove (#if 0) unused functions These were revealed after fixing DUK_SINGLE_FILE, gcc will complain about these internal functions being declared, defined, but not used. There were also a few declared functions that did not exist. Compiled binary size was reduced by a few kilobytes! Unused functions must be commented out carefully: some functions might be used with certain feature options but not by the defaults. These removals were verified with grep. There are no call sites for DUK_DEBUG_DUMP_HEAP() so all the functions in duk_debug_heap.c are unused, even with a debug build. Out of the checked allocation macros, only DUK_REALLOC_INDIRECT_CHECKED() is actually in use at the moment. This commit just comments the unused stuff out, but it might be better to just remove the unused stuff entirely.	10 years ago
Sami Vaarala	e1d13db74f	Capitalize Duktape internal strings (\xFFValue)	10 years ago
Sami Vaarala	1fa66cd25a	Symbol visibility changes for code and headers	10 years ago
Sami Vaarala	3ab572de8a	Code policy issue fix trivia	10 years ago
Sami Vaarala	58f78912ea	Dprint native __func, eliminate FIXME	10 years ago
Sami Vaarala	06ece2a447	FIXME cleanups	10 years ago
Sami Vaarala	d0f92911e3	Rename duk_hobject e_used to e_next for clarity e_used is actually used to track the number of entry part entries currently GC reachable. Some of the entries may be NULL, indicating deleted keys. The e_used value is also used as the index where the next insertion of a new property key happens, so e_next is probably a more appropriate name and doesn't incorrectly imply that the e_used count indicates actually used, non-NULL key entries.	10 years ago
Sami Vaarala	c9094995c2	/Wp64 fixes for VS2010 on x86	10 years ago
Sami Vaarala	6a15c0be73	Formatting casts for custom format (%!T etc)	10 years ago
Sami Vaarala	018774dc55	Format string cleanups, %ld instead of %d etc	10 years ago
Sami Vaarala	8df41e7289	Add missing %c for debug formatter	10 years ago
Sami Vaarala	ab0f8265c0	Add support for %ld/%lu/%lx to debug formatting These should be used together with a "(long)" or "(unsigned long)" cast to make debug prints portable and ensure 32 bit integers format correctly.	10 years ago
Sami Vaarala	f8423ffb36	Format string cleanups, allow NULL+%s/%p in debug Lots of minor string format cleanups (casts mainly). Add a special check to detect NULL pointers with %s/%p formats in debug logging to avoid calling the platform sprintf() with a NULL value. This is especially important for %s + NULL, which is not portable and may crash on some platforms. Debug logging will now format these specially as "NULL" and avoid calling the platform for formatting, so debug log call sites don't need to be careful with NULL pointers any more.	10 years ago
Sami Vaarala	ddd0619f78	Intermediate commit of compiler typing cleanup	10 years ago
Sami Vaarala	88e1c199ae	Debugging code type cleanup	11 years ago
Sami Vaarala	8ef70ac788	Fix e_idx and h_idx typing (duk_int_t)	11 years ago
Sami Vaarala	1a4f3c2536	fixme cleanups	11 years ago
Sami Vaarala	b9b578a2eb	rename special->exotic in code	11 years ago
Sami Vaarala	25f7fcbc32	fix old debug reference to thr->errhandler	11 years ago
Sami Vaarala	2b0bf5f285	remove errhandler_index from protected call handling, and fix call sites in Duktape internals	11 years ago
Sami Vaarala	59b5591e5a	large expression fixes for INITSET/INITGET (which now have indirect variants) and PUTVAR	11 years ago
Sami Vaarala	1b36288b1f	move INC, DEC, UNM, UNP to extraops to make room for MPUTARRI, MPUTOBJI (indirect variants); add shuffling special handling for MPUTARRI and MPUTOBJI to allow literals in large expressions	11 years ago

4 Commits (8441bdbad78f0dedbd5f791df7396b6fd6665934)