You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
This is not immediate issue, but for tracking
Background:
From early experiment, I found some cases:
for (init; cond; update) body
init
,cond
,body
,update
switch (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.
The text was updated successfully, but these errors were encountered: