I'm not sure if LegNeato made a Freudian slip, but comment 38 is very suspicious. It's also welcome news in case PPC JM+TI runs aground, because we could probably hack tracejit to work by itself in the ESR if we had to.
Two bits of bad news on methodjit. The first bit of bad news is that type inference requires the CPU to have a square root instruction, and only G5 does. We could emulate this on G3 and G4, but it would be expensive, of course. Assembly jockeys, here's your chance: come up with a routine in assembly to do PPC square root without a lookup table (you can use a couple constants if you like). It doesn't have to be fast because it's going to suck anyway; it just has to work. This routine might give you some ideas. Post your entries to issue 96; the winner gets beer.
The second bit of bad news is that we have some serious problem with how JavaScript stack frames are managed (not to be confused with the VMFrames we generate in methodjit), and it's not even in the code I wrote. I'm not sure if it's a compiler fart or not. This might be the explanation for some of the serious slowdowns on some sites, and it's possible the problem was there all along and it's just JM+TI that unmasks it. The problem crops up when nesting JS stack frames and if all else fails, I might be able to hack the interpreter to just turn TI off and drop to JM alone if the situation occurs. But that eliminates the entire advantage of JM+TI in the first place, and still isn't as fast as tracejit.
Life sucks. More later.
Seems like 10 may indeed be the ESR:
ReplyDeletehttp://blogs.usenix.org/2011/12/07/mozilla-adds-extended-support-release-structure-to-firefox/
That'd be nice...
Hi 10FF dev team,
ReplyDeletethanks for all the efforts! Your work is superb!
about square root - don't give up - http://www.opengl.org/sdk/docs/manglsl/xhtml/sqrt.xml
GLSL has square root since OpenGL 2.0
You can apply this even for PowerPC G3.
Yeah, I saw that too. However, I haven't seen any other preparations or a new tree appear, and 10 is now in beta, so ...
ReplyDeletePerhaps it will emerge after 10 becomes release.
paraflow, thank you for your link, but what we need is a square root in assembly language that can be inlined. Right now we're looking at either patching the JS interpreter to not insert the square root instruction (by not "promoting" Math.sqrt) or use an inverse inverse square root routine (Carmack's inverse sqrt from Quake 3). Neither will be as fast as the G5, which has a square root instruction, but we just have to get it to work. Still, if you have one, submit it.
:) haha, I'm far away form contributing for PowerPC platform :) My self I'm a java developer and javascript developer.
ReplyDeleteBut still I don't understand, why you guys restrain from using OpenGL 2.0 and GL Shading Language (cause that give power even to G3 users)
Because 10.4 PPC doesn't support OpenGL 2 and I've seen no convincing evidence that dylibs can be built that enable that support (and even if so, most of the G3-compatible video cards are not capable of it). If you believe this is important and possible, perhaps this can be your first contribution to PowerPC. ;)
ReplyDeleteHere is a "silly" idea. Since 10 is going to be the ESR, and since you've managed to keep source code parity all the way to 10, and keep PPC users current, how about asking Mozilla to accept your patches back into the "official" firefox 10 ESR branch?
ReplyDeleteEven if there is no mozilla support after 10, this will go a LONG way for helping ... well, every linux and mac PPC user out there.
You've managed to get Tracejit working for PPC code, as well as MethodJit, right? MJ needs type inference as an optimization still, but Tracejit is (did I understand correctly) officially supported in 10, just not in 11. So you've done all the hard work for them.
A very logical suggestion. There's a few wrinkles though.
ReplyDelete- The POWER and PowerPC generic stuff is going to be shipped back to the tree (in the case of tracejit, it already was, but got bogged down in review and now that tracejit is dying is irrelevant; see bug 624164). We've already submitted various endian and other minor fixes back to Mozilla (bug 712990, bug 713463), and I plan to submit our JM+TI backends when we are sufficiently satisfied with them. Not only are they atomic, so they are unlikely to rot on the vine, but they are also suitably applicable to Linux, *BSD, OS X PPC and AIX, giving them a good range of consumers.
- PPC OS X specific stuff is probably not worth shipping back for a couple reasons: dropping 10.5 is already getting bounced around, and the pieces to get 10.4 to compile require gutting gfx/ and plugins in ways that will not pass tests perfectly and therefore will not be approved (and it's not worth getting them to do so, if even possible). Plus, Mozilla is certain to break them anyway.
- PPC OS X integration pieces of JM+TI will not be shipped back either, for the same reasons -- they're going to be obsolete, and Mozilla is not likely to keep them in good repair. It's easier for us to watch for bustage on our end than fight with the slow Mozilla review processes to get fixes back in the tree. They will also be irrelevant to Linux anyhow, because Linux uses a somewhat different ABI, so those pieces would need to be rewritten for Linux in any case.
Note that we offer our patches freely anyway, so even if we didn't want to put things in mozilla-central people can still get the source code.