3 ms·

OdinMonkey is: a separate front-end for optimizing compiler (one that translates JavaScript code to compiler IR), a couple of IR instructions specific to asm.js

by mraleph 13y ago

OdinMonkey is: a separate front-end for optimizing compiler (one that translates JavaScript code to compiler IR), a couple of IR instructions specific to asm.js (e.g. asm.js heap access), plus AOT linker, trampolines for transitioning to/from asm.js code and some runtime infrastructure specific for bounds check elision on 32-bit platforms. Potentially there will also be a separate parser added to the mix. The code generation back-end and middle end are the same as IonMonkey uses (sans code generation patterns related to added IR instructions). Overall both start of asm.js code compilation and end are highly customized and different from what happens to normal JS functions. Whether this constitutes a separate pipeline or not is debatable. I think it does because none of this custom stuff is running for normal JavaScript no matter how you write it until you put "use asm"; in the right place. I am not debating that it is build on top IonMonkey though (my post from April states exactly that). [One additional thing to notice is that asm.js typing rules are clearly at least partially duplicate what IonMonkey type inference already should infer statically for the JavaScript code, at the same time, if I am not mistaken, there is little sharing going on between OdinMonkey type-checker and TI engine.]

azakai 13y ago
> Whether this constitutes a separate pipeline or not is debatable. If this comes down to the semantics of "separate pipeline" then maybe that is pointless. There is some new stuff at the start and end of processing, as you say, but all the middle is shared, and that is by far the bulk of the code. IMO it comes down to the fact that one developer wrote all the new stuff at the start and the end in a few short months. Compared to a team that took years to write IonMonkey and other parts of the JS engine that are shared. So calling this a new VM or new JIT is definitely wrong, and even calling it a new pipeline feels like an odd choice of words, since the "pipeline" used on asm.js code is almost entirely of the existing SpiderMonkey VM.

by mraleph 13y ago

azakai 13y ago

> Whether this constitutes a separate pipeline or not is debatable. If this comes down to the semantics of "separate pipeline" then maybe that is pointless. There is some new stuff at the start and end of processing, as you say, but all the middle is shared, and that is by far the bulk of the code. IMO it comes down to the fact that one developer wrote all the new stuff at the start and the end in a few short months. Compared to a team that took years to write IonMonkey and other parts of the JS engine that are shared. So calling this a new VM or new JIT is definitely wrong, and even calling it a new pipeline feels like an odd choice of words, since the "pipeline" used on asm.js code is almost entirely of the existing SpiderMonkey VM.