5 ms·
> I don't understand desire to have another compilation pipeline on the side, if everything that is needed can be implemented in the main compilation pipeline a
by azakai 14y ago
> I don't understand desire to have another compilation pipeline on the side, if everything that is needed can be implemented in the main compilation pipeline and benefit JavaScript as whole, without restraining users to a strongly typed subset. This also leads to an unnecessary duplication.
There is hardly any duplication. All the optimizing machinery is being reused entirely. asm.js code is fast because the existing IonMonkey code generation makes it fast.
The only new part is something - the OdinMonkey module - that type checks asm.js code, and if it validates, then it feeds that into the existing IonMonkey compiler, with the types that were discovered during type checking.
- kevingadd 14y agoAnd disables the generation of type checks and bailouts in the output, yes?
- azakai 14y agoAs part of feeding the type info, it is clear that various type checks are not needed, yes.
- mraleph 14y ago> There is hardly any duplication. There will be a clone of JavaScript parser. IR building is already duplicated as well. I am aware that middle-end/back-end are shared, though there are some IR instructions are that specific for asm.js. But I agree: duplication might be the wrong word here.
- azakai 14y agoI am actually not a supporter of a custom parser. But yes, it might end up happening.