- Switch improvements:
- JSOP_CONDSWITCH is a 1 byte nop, not variable length with the same kind
of immediate operand as JSOP_LOOKUPSWITCH (which is useless except for
decompilation). New scheme uses SRC_COMMA notes on each JSOP_CASE opcode,
usually 2 bytes per note, and a typically-1-byte 2nd offset on SRC_SWITCH:
1 + 2 * ncases
vs. the previous JSOP_LOOKUPSWITCH immediate, which consumed:
4 * ncases
bytes after the switch opcode just for decompilation.
- SRC_SWITCH has two offsets, first to end of switch as before, the second
to first case if JSOP_CONDSWITCH, for decompilation.
- Optimize switches with all-constant cases using JSOP_TABLESWITH, or if
that can't be used, JSOP_LOOKUPSWITCH, before falling back on ECMAv2's
JSOP_CONDSWITCH.
- Use cx->gcDisabled when evaluating case exprs at compile time for old,
pre-ECMAv2 switches, to prevent branch-callback-based GC invocations
from ripping apart the unrooted temporary script for each case expr.
- Fixed up stale SRC_SWITCH comments in jsemit.h.
jsemit.c jsemit.h
- TREE_CONTEXT_INIT to match ATOM_LIST_INIT, not English word order.
- Reorganized JSCodeGenerator to sort of match argument order to
js_InitCodeGenerator.
- Got rid of confusing CG_RESET* macros and used memset(cg, 0, sizeof *cg)
and non-zero-default init in js_InitCodeGenerator. js_ResetCodeGenerator
just releases the code and temp arena pools and leaves the cg in a state
where it must be re-initialized (as before, but more obvious).
- In the same spirit, don't do partial "resets" or src and trynotes in their
js_FinishTaking*Notes functions -- those are friends of jsscript.c and are
not general, idempotent functions.
jsapi.c jsapi.h jsarray.c jsatom.c jsatom.h jscntxt.c jsemit.c jsmsg.def
jsnum.c jsobj.c jsopcode.c jsregexp.c jsscan.c jsstr.c jsxdrapi.
- Use PR_snprintf rather than sprintf always, so we don't have to worry
about systems with 64-bit longs that overflow 12-byte buffers and open
Morris-Worm-type security holes.
- Trim extra spaces, fix hanging indentation, and similar anal retention.
- Renamed JSMSG_BAD_PROTO_SORT to JSMSG_BAD_SORT_ARG cuz that's what it
is complaining about.
- SRC_CATCHGUARD still lived in comments, but it's SRC_CATCH in code.
jscntxt.c jscntxt.h jsinterp.c
- Packed nearby JSPackedBools and added a new one: gcDisabled, for use by
jsemit.c's pre-ECMAv2 switch case expr eval.
- Rip out old js_InterpreterHooks stuff from original liveconnect (moja).
- Remove javaData and savedErrors from JSContext. Leaving it to fur or
shaver to remove javaData from jsscript.h.
Including:
Preliminary work on internationalizing error messages
Preliminary work on exposing runtime errors as catchable exceptions
ECMA-proposed throw and try/catch/finally, with multiple catch clauses
and catchguards
ECMA-proposed in/instanceof operators
IEEE-conformant number to string conversion
Fixes and other good stuff.
cast until after the double in question has been determined to be
finite, not NaN, etc. This may make the code a little more XP for
platforms like BSD and Alpha Linux that don't like casting strange
values to int. Thanks go to Uncle George <gatgul@voicenet.com> and
hankin <hankin@consultco.com> for their porting work.
- Revise exception handling runtime info (now called trynotes a la srcnotes)
for more efficient loop control under JSOP_THROW. Avoid all uses of catch
and throw while at it, to make C++ lusers happy.
- Combine JSStackFrame.exception with rval, and rename
JSStackFrame.exceptPending to be ...throwing.
- Optimize JS_TypeOfValue a bit.
- Name, control flow, whitespace, etc. cleanup.
It now passes all of the tests in 15.1.2.2-1 (except that parseInt
still has the .length property, which is a different bug) - so I'll
close the bug.
Still possibly at issue is whether we conform to ECMA language about
decimal numbers that are too large to fit in a double. I treat
decimal digits after the 20th as zero, but there could be some
floating-point rounding wackiness going on. In particular - are we
doing the right thing for numbers that are powers of 2, but larger
than 2^54, that are representable in a double?