On 5/18/16 10:41 PM, Jan de Mooij wrote:
They do get the baseline compiler, which can still be significantly faster than
the interpreter, but Ion requires SSE2. Since the runtime detection does just
turn Ion off altogether, I don't know if we would gain much by removing it (the
ability to disable Ion isn't going away).
We will have to make a similar decision for WebAssembly. Odin (our
Ion-based asm.js compiler) requires SSE2, but there we can at least
use the much slower 'normal JS' path. For WebAssembly, we have the
following options IIUC:
(1) Don't support wasm on those ancient CPUs. This may work for a
while, but at some point we may include wasm modules in Firefox and
add-ons, normal websites will start to use it, etc.
You'd also have to make this decision for non-x86/non-ARM. Along with
oxidation that would be a portkiller for the few weird architectures
still hanging on if you didn't do:
(4) Add a wasm interpreter. Again, likely not worth the effort if it's
just for this.
One of the really nice things about working with SM is that I can fall
back on the interpreter when things go wrong, and/or use it as a point
of comparison for testing, so doing so has benefits beyond just getting
Tier-3 or unsupported systems functional.
Cameron Kaiser
ein guter Tier-3kenner
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
