Be careful... that transformation is not valid, i.e. obj[i++] += 1;
is not equivalent to obj[i++] = obj[i++] + 1
Oh well, I'll try to find a way to generalize the code generation for assignments.
the semantics of JavaScript (if I recall correctly) requires that
all the properties of the object *at the moment the for-in loop is started* must be iterated on by the loop. [...] the best I can think of is the conversion of the hashtable into an array at the moment the for-in loop is entered, and then the for-in loop is just a normal for loop iterating over the elements of the array.
Then we will probably want an instruction to get an array of available property names, and perhaps later make a special case for arrays.
Seems fine. How will this impact performance?
The new instruction constructors will be closures assigned to globals, eg:
var AddInstr = makeInstr(...);
Where makeInstr is the function that creates the closure in function of the number of parameters desired, the desired instruction mnemonic name, the parent instruction, and other parameters, such as a handler function we might want to associate with this instruction, etc.
The resulting code might be slightly less fast, but it won't be an impossible optimization challenge. I also don't think that instantiating instructions is a performance bottleneck.
That's what I did for the first version of Gambit. I ended up with
more than 5000 lines of assembly code... not a good thing.
I'd like to try and see what it looks like for a small subset of JS (enough to implement fibonacci, quicksort, etc.), just to see what it looks like, and then examine ways of expressing the same handlers in portable MIR/LIR.
- Maxime