This is not immediate issue, but for tracking
Background:
- BinAST file encodes interface fields in IDL's order
- Given we encode scope information, at the point of reading each node, it's ready to compile the code to bytecode or machine code
- Currently IDL uses the syntax order for each field
- There are some differences between syntax order and execution order
- Some optimizations might be possible if some other fields are encoded in different order (this mostly depends on implementation)
From early experiment, I found some cases:
for (init; cond; update) body
- execution order is:
init, cond, body, update
switch (discriminant) { case C1: body1; case C2: body2; ... }
- jump operation can be optimized if case values are all known before reading bodies
there may be other cases.
on SpiderMonkey, we're going to compile BinAST file directly to bytecode, and if the IDL order matches to bytecode order, the compilation can become simpler.
to be clear, I'm trying to avoid modifying the IDL order just for SpiderMonkey's benefit, so we need to figure out other engine's situation as well.
This is not immediate issue, but for tracking
Background:
From early experiment, I found some cases:
for (init; cond; update) bodyinit,cond,body,updateswitch (discriminant) { case C1: body1; case C2: body2; ... }there may be other cases.
on SpiderMonkey, we're going to compile BinAST file directly to bytecode, and if the IDL order matches to bytecode order, the compilation can become simpler.
to be clear, I'm trying to avoid modifying the IDL order just for SpiderMonkey's benefit, so we need to figure out other engine's situation as well.