catch { catch { break foo; }; };

I've now added a few peep-hole optimization rules. The test program "foo: for(;;) { catch { catch { break foo; }; }; }" is now reduced from:

~~~ 1 0 byte(3) ~~~ 1 1 byte(3) ~~~ 1 2 entry ~~~ 1 3 function start ~~~ 1 4 label(0) ~~~ 1 5 label(4) ~~~ 1 6 catch(5) ~~~ 1 7 catch(7) ~~~ 1 8 escape catch ~~~ 1 9 escape catch ~~~ 1 a branch(2) ~~~ 1 b label(8) ~~~ 1 c exit catch ~~~ 1 d label(7) ~~~ 1 e pop ~~~ 1 f label(6) ~~~ 1 10 exit catch ~~~ 1 11 label(5) ~~~ 1 12 pop ~~~ 1 13 label(3) ~~~ 1 14 catch(5) ~~~ 1 15 catch(7) ~~~ 1 16 escape catch ~~~ 1 17 escape catch ~~~ 1 18 branch(2) ~~~ 1 19 exit catch ~~~ 1 1a pop ~~~ 1 1b exit catch ~~~ 1 1c pop ~~~ 1 1d branch(4) ~~~ 1 1e label(2) ~~~ 1 1f push int(0) ~~~ 1 20 return

to:

=== 1 0 byte(3) === 1 1 byte(3) === 1 2 entry === 1 3 function start === 1 3 return 0

Which I find hard to optimize any further... :-)

/ Henrik Grubbström (Lysator)

Previous text:

2002-09-23 22:25: Subject: catch { catch { break foo; }; };

---

I've replaced the use of throw(0) to exit catch blocks normally with an opcode that uses a normal return instead of a longjmp.

At the same time I changed the default return value from catch blocks to UNDEFINED (it was a "plain" zero earlier), only because I think it's a little cleaner. I don't think it has any practical compatibility impact, but there might be other opinions?

/ Martin Stjernholm, Roxen IS