Monday, May 27, 2013

IonMonkey PowerPC phase 2 complete

We've moved from phase 1 (putative construction) to phase 2 (successful compilation and linking). It makes a big mess and immediately segfaults, but at least it builds. A portion of mild concern was that AsmJS requires an exception handler (!), so I'm hoping it can still be properly disabled in 24 (#undef JS_ASMJS) or we could have some difficult to debug problems with asm.js scripts. For the remainder of 22 I'll be filling in more gaps, but I won't be able to do much more testing until 24-aurora.
Posted by at

8 comments:

  1. AnonymousMay 28, 2013 at 8:53 AM

    I may be a bit rusty on my history, but don't you hack PPC assembly too? Isn't PPC assembly rather advanced compared to the old i86 instruction set? So couldn't, in theory, the new asmjs output to PPC code too, with the proper hacking?

    Or am I totally wrong and this is not the problem with the new asmjs thingy?

    ReplyDelete
    Replies
    1. ClassicHasClassMay 28, 2013 at 4:56 PM

      No, it should be perfectly possible to emit PPC equivalents for asm.js. Strictly speaking, once IonMonkey is operational, asm.js should "just work" with the proviso that Mozilla's Mach exception handler still works fine on PPC 10.4 and 10.5 (not at all guaranteed). However, we probably won't have IonMonkey fully working for 24, just BaselineCompiler, and too many things compiled with asm.js assume little endianness which will require a larger solution. So I'm going to leave it "disabled" for this cycle.

      Note that disabling asm.js just means it won't emit the optimized code and will use the regular JIT, so those scripts will still run (since asm.js is, after all, just a weird subset of JavaScript).

      Delete
  2. niu techMay 31, 2013 at 3:42 AM

    Camino is now officially dead, so TFF is the only supported browser for Mac PPC (except QupZilla via MacPorts) :(

    ReplyDelete
    Replies
    1. ClassicHasClassMay 31, 2013 at 7:31 AM

      I saw. :(( (See new blog post.) At least for the moment SeaMonkeyPPC still issues updates, but I think that's the only one for Gecko browsers other than us. I'm not sure about the future of Roccat or the other WebKit shells, or OmniWeb.

      Delete
    2. TobiasMay 31, 2013 at 9:53 AM

      Recently Roccat 3.2 was released and it still runs on PowerPC Macs (although to me it seems those social features don't really work in 10.5). Together with Leopard WebKit you get an actively supported browser - although there's still no JavaScript JIT compiler in there.

      I didn't know of qupzilla yet and never bothered trying to build whole Qt4 myself in order to try a QtWebKit browser. The underlying WebKit sources are from May/June 2011 and as Qt5 depends on Google's V8 JavaScript engine it will definitely be the last version of Qt (4.8 I mean) and QtWebKit (the rendering and JavaScript engine) that will work on PowerPC Macs.
      So while the frontend of qupzilla may support Qt4 for quite some more time, Qt4 itself (and QtWebKit as part of that) will receive bug and security fixes only.

      Until now I myself prefer old Safari 5.0.6 together with the current Leopard WebKit.

      Delete
    3. niu techJune 1, 2013 at 3:17 PM

      I didn't know about Roccat, it seems to be slightly faster in V8 benchmark than Safari. But Leopard WebKit has higher score in HTML5 Test, like TFF.

      QupZilla uses QtWebKit 2.2, but it should be able to compile with the recently introduced QtWebKit 2.3.

      Delete
    4. TobiasJune 2, 2013 at 5:52 AM

      QtWebKit2.3 will need some of the patches from https://bugs.webkit.org/show_bug.cgi?id=103128, more specifically at least the one that was incorporated into QtWebKit 2.3 for fedora linux.
      Later versions will need all of those patches in case they haven't been merged into WebKit trunk until then.

      For your info: the WebKit application from Leopard WebKit just launches the installed version of Safari forcing it to use the WebKit frameworks that are embedded into the WebKit application. The installation script replaces the installed system frameworks with those embedded ones so that any application (like Safari, Mail, Dashboard, Roccat, iCab, Stainless, ...) benefits from the updated ones.

      Since the original JavaScript interpreter was removed from WebKit and instead an generic interpreter (called the "C loop backend" for the "LowLevelInterpreter") has to be used, JavaScript is somewhat slower in recent versions of WebKit >537.12. That's most probably also true for QtWebKit 2.3.
      But in turn the rest of the rendering engine is noticeably faster, at least in Cocoa WebKit (to differentiate it from QtWebKit).

      Delete
  3. TobiasJune 2, 2013 at 5:51 AM

    This comment has been removed by the author.

    ReplyDelete

Due to an increased frequency of spam, comments are now subject to moderation.

Subscribe to: Post Comments (Atom)