On Sun, May 22, 2016 at 10:43 PM, Cameron Kaiser <ckai...@floodgap.com> wrote:
> 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. > I don't know if an interpreter is planned, but there's at least a baseline compiler in the works: https://bugzilla.mozilla.org/show_bug.cgi?id=1232205 _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
