Pitch into the Firefox JIT


On the suggestion of a few people, and the fact my time is somewhat more curtailed due to my attempts to do hal-fassed continuous integration testing on ppc64le Firefox and maintain TenFourFox for a still resilient 32-bit Power Mac crowd (and my day job, which as some of you know has pretty much zilch to do with this type of thing), I've uploaded the work so far on the Firefox JIT to a Github repo so that additional people who want to contribute can. The repo is live now.

I think I've documented most of it in the readme, but here are the highlights. Much like TenFourFox's IonPower, some of which was converted to 64-bit and transplated into this new JIT, the Power ISA JIT uses MIPS as a scaffold to hang new code off of. This is particularly handy since many of the MIPS instruction sequences have similar or direct correlates to PowerPC (like lui ori and addis ori), MIPS also uses a link register, and MIPS doesn't have some of the encoding idiosyncrasies of ARM.

The minimum viable product I'm shooting for is a little-endian 64-bit JIT with Wasm for the POWER9. It's not that big-endian isn't desirable or that it shouldn't run on anything earlier than a Talos, but I also know that for MVPs the last thing you want is having to boil the ocean and these are things that can be added after the fact. We also can use all the nice new P9 instructions and avoid endian glitches in the JIT core by concentrating on LE POWER9.

You can see the work I've done already; pretty much anything with a -ppc64le in it is a file I've either completed (the majority) or started work on (the MacroAssembler). The macro assembler, architectural definition and low-level direct assembler are the major pieces still left to do in the first draft before trying to get it to build. I've based this off Firefox 62 not because there's anything special about that version but because it was the version in release when I got started and having to react to code changes with succeeding versions would have slowed down the first draft. When we get it up there then we can forward port it and pick up any additional changes we need to make to the backend along the way.

Finally, this repo is merely a means to the eventual end of getting the JIT to live in the Mozilla tree and be maintained there. This is simply a temporary measure to get more collabourators and get it off the ground.

I'll still be working on this personally, of course, and I'll be doing it more once I get the current TenFourFox release into beta, but I think that we all want good browser choices on POWER9 and while Firefox is perfectly usable on my Talos, it's certainly not the best it could be. This way people can see progress is being made and those who have the technical chops can contribute to make a great platform even better. Further posts as we reach additional milestones. If you want to contribute, open issues and file PRs and I'll deal with them promptly.

Comments

  1. "There is certainly interest and value in big-endian and additional 64-bit PowerPC support (potentially all the way down to the 970/G5), but these can be grafted on after the fact."

    Will Mozilla allow us to add this support "after the fact"?

    Will you, or the community at large, actually work to get this support added "after the fact"?

    My experience has been if you start with an LE port, that's what you get - nobody will care about a BE port because it's "old" (even though calling BE support "old" is FUD).

    ReplyDelete
    Replies
    1. At least in my experience, Mozilla has allowed BE patches in other sections of the tree as long as they weren't highly disruptive. The patches I needed to get TenFourFox working with Ion were not extensive, though that's 45-era, so I don't know if more work is needed.

      As far as a "after MVP" party, I'm happy to facilitate getting such support in the tree. If you're asking me whether I'm going to *write* it, though, the answer has to be no. I don't have a BE ppc64 machine running Linux, and I don't have any reason to currently, so I don't have any means to test it. That said, I've tried very hard in the code I've done so far to flag areas I think could be an endian hazard, and I've not done anything irrevocably LE that I know of.

      Delete
    2. I already assumed I'd be the one writing it. No harm done. Thank you for flagging potential endian issues ahead-of-time; I wasn't aware, as I haven't had time yet to look at the sources.

      As I have the exact opposite issue (I have no LE ppc64 machine, and I don't have any reason to have one), I'm afraid I won't be able to be much help until it can be ported. I wish you (and the community) speed and luck, though.

      Delete
  2. Thanks for what you're doing , it's really appreciated :)

    ReplyDelete
  3. I want to thank you for your work aswell! If you need testing or anything else: I have a 10-Core POWER8 machine and soon a #Blackbird at home. So just tell me, if you need any resources...

    ReplyDelete

Post a Comment

Comments are subject to moderation. Be nice.