4 ms·
> - will only run on the hardware platforms for which you have developed. What fast browser JITs are actively developed for platforms other than ARM, AMD64 and
by ihnorton 13y ago
> - will only run on the hardware platforms for which you have developed.
What fast browser JITs are actively developed for platforms other than ARM, AMD64 and IA32? V8 does not support anything else, and while Firefox enables SpiderMonkey for MIPS and SPARC [1], "unsupported" is not a very hearty endorsement.
https://developer.mozilla.org/en-US/docs/SpiderMonkey/1.8.8#Platform_support https://developer.mozilla.org/en-US/docs/SpiderMonkey/1.8.8#...
- bzbarsky 13y agoSpiderMonkey works on PPC, for what it's worth; the TenFourFox project is actively maintaining it there. They're usually a bit behind on porting the JITs, but they do actively port them. But the real issue with NaCl is this thought experiment. Assume NaCl were developed in 1998 and everyone had jumped on that bandwagon and the web in 2003 were full of NaCl blobs targeting the hardware architectures that mattered in 2000-2001. Then ask yourself the following questions: 1) Would this have affected the choice of hardware for phones and tablets and whatnot? 2) Would it be viable today to ship a web browser on an ARM system? 3) What makes us think that the currently-relevant set of hardware architectures will still be the set we want to be using in 10-15 years? In 30 years? The nice thing about asm.js or PNaCl compared to NaCl is that even if we ship it right now and only run it right now on ARM/AMD64/IA32, if someone comes up with a new hardware architecture they want to ship in consumer devices they can simply implement a JS JIT for it (in the case of asm.js) or an LLVM backend (for PNaCl), which is something they would need to do _anyway_ for that "consumer devices" bit. On the other hand, if they have to deal with legacy NaCl content they suddenly have to do hardware emulation or something insane.