• Updated 2023-07-12: Hello, Guest! Welcome back, and be sure to check out this follow-up post about our outage a week or so ago.

Firefox 5 not on Tiger PowerPC :(

Gorgonops

Moderator
Staff member
I know this is an incredibly ignorant question, but would the same barriers that prevent building a "native" Firefox 5 on older versions of OS X apply to building an X11 version of it? (IE, just pretending that "Tiger" is a vanilla BSD variant and taking that route.) Obviously that would be a suboptimal solution to the problem but I'm curious if it would be "possible".

 

ClassicHasClass

Well-known member
Firefox has Google Chrome version number envy ;)

The problem appears to be linking (either [but probably both] of dyld and ld). Mozilla requires a superlibrary called libxul to be constructed no matter what platform, and it appears that Tiger can't cope with that regardless of it being targetted to X11 or Aqua. A couple inventive sorts with custom build tools are investigating, but even if that is fixed there is no guarantee the patches to Chromium IPC are going to work either.

 

ChristTrekker

Well-known member
Yeah, I don't know why they chose Chromium code for that, especially with NSPR being in-house, but there it is.
Please bring this down a notch on the geek-speak-ometer so the rest of us can understand what this means and why it's a problem. :)

 

ClassicHasClass

Well-known member
PowerPup, run it on Tiger if you can -- there's a widget bug that affects Leopard that I'll have fixed in beta 2.

The NSPR bit: Chromium has a system abstraction layer in it that Chrome/Chromium use to abstract functions between Windows, Mac and POSIXy Un*x. Mozilla has had such a glue library for a lot longer, as evidenced by the name: the "Netscape Portable Runtime." NSPR is much more comprehensive, and at one particular point in the past it simultaneously had support for Mac OS 8/9, Windows, early OS X, BeOS, OS/2, a wide variety of Unices including Linux, *BSD, Solaris, AIX, etc., and even VMS and some other exotics. NSPR was as the name implies a holdover from the Netscape Classic days, where it handed System 7, Windows 16/32 and numerous Unix ports. My ANS even has Netscape on AIX 4. If you want Mozilla code to run on your system, you must port NSPR, which was the first thing Timberwolf had to do to get it on AmigaOS 4. Classilla is also based on NSPR, just an earlier version that still supports OS 9 with of course my patches stuck in it, and TenFourFox uses a tweaked NSPR that still runs on 10.4.

So the question was why Mozilla chose Chromium to handle their IPC instead of rolling their own, and I guess it was just the path of least resistance. But they didn't do (just) that; rather than port Chromium IPC to talk to NSPR and just have it use NSPR for the system guts, they decided to bring its entire system abstraction layer with it. Chromium IPC in TenFourFox is super-gutted; most of it doesn't even work. It's only there to provide stubs to make Mozilla happy, because there are other pieces of code I wrote to route around it. This will only work for so long because 10.4 lacks posix_spawn and Chromium IPC absolutely requires it, which is why plugins will never run out of process in 10.4Fx. When Firefox goes fully multiprocess, which fortunately is at least several versions away, we're going to have another fish or cut bait moment.

 

PowerPup

Well-known member
Seeing how posix_spawn() (or for 10.4 the lack thereof,) is one of the issues with compiling Firefox 4 & 5 (and future versions.) I thought I'd do a little googling and learn some more for myself.

I learned (and am explaining it for the benefit of non-programmers like me,) that posix_spawn() creates a new child process without having to fork (clone) the parent process. Using the method before posix_spawn(), which is a combination of fork() and exec(), would be slow and inefficient as it would have to make an entire copy of Firefox before replacing it with the appropriate plugin. (QuickTime, Flash, etc.)

So I ventured on to see if the was a way to create a child process without forking besides posix_spawn()... And there doesn't seem to be. Which seems really weird to me because it would seem to me that that kind of function would have been implemented in Posix systems a long time ago when memory was limited. (But then again, programs were smaller. :p )

I did find the following on opengroup.org:

The posix_spawn() function is implementable as a library routine,* but both posix_spawn() and posix_spawnp() are designed as kernel operations. Also, although they may be an efficient replacement for many fork()/ exec pairs, their goal is to provide useful process creation primitives for systems that have difficulty with fork(), not to provide drop-in replacements for fork()/ exec.
* --Underline added by me.
So it sound like it is theoretically possible to add posix_spawn() as a library, making it unnecessary to do any modification to the system... At least, it sounds possible...

Ooo, I just found this: http://stackoverflow.com/questions/4463283/managing-process-forks-in-c-in-linux-unix/4463468#4463468 (Comment #2.)

Note that on systems without posix_spawn, it's trivial to implement it as a library routine on top of fork (or better yet, on top of vfork if it's available)
(Which vfork() has been around since 10.3 as best as I can tell.)
I've found the opensource code for Apple's posix_spawn() scattered across it's Libc and xnu source in Leopard. Which makes it sound like it's integrated into the kernel. Still, it sounds like if we could somehow find and port over a c library (like FreeBSD's or something,) we could possibly get posix_spawn() in Tiger.

Note that this is just all positive speculation from me as I am trying to comprehend things that are out my league. :p

@CHC: Will do, Tiger is all I have. ;)

Update: Well I'm currently posting from TFF5 on my PowerBook G4. It indeed feels snappier than 4.0.1 (I had b1 on it.) The first time I tried to quit TFF5 it was taking forever so I force quit it. But it's working fine now. I'm not experiencing the widget bug that's on Leopard, but the bookmark menu does seem to be unusually wide. Although it's completely functional for me.

I'll try to test TFF5 on my Lombard and Sawtooth over the weekend if I have the time. ;)

Sunspider results: 7736.9ms

Not as fast as a G5, but at least it ran the test. 4.0.1b1 wouldn't even run it for me. :p

 

ClassicHasClass

Well-known member
No, posix_spawn can definitely be implemented in userland, but all the implementations out there are kernelspace. But great suggestion on OpenGroup (why didn't I think of that?!), because after some fiddling around on their site, I finally found their "ideal" userland posix_spawn, and we can use that. It will be a bit slower, but it should work. We can't use the *BSD ones, sorry, those are kernel-land (I already looked into it and it was the first place I thought of). For posterity, we'll build on this: http://pubs.opengroup.org/onlinepubs/000095399/xrat/xsh_chap03.html

NSPR does use posix_spawn too, but only as a fork() substitute, and waaay back in one of the Firefox 4 betas I already rewrote it.

Nevertheless, the current system works and I won't worry about this until Mozilla makes us worry about it. But thanks for giving me the right place to look!

I already fixed the bookmarks menu. Amusingly, this section of code is nearly identical to the section in Classilla, with some changes for CoreFoundation. Mozilla pulled the old OS 9-era code and put in an Obj C function that doesn't seem to handle the UI correctly, so I reverted it.

 

PowerPup

Well-known member
No problem, happy to help in any way I can. If something useful for the future of TFF came out of that 2 hours of googling, then it was time well spent. ;)

Ah, so you found a useland posix_spawn. Guess I should have looked on OpenGroup more. (I was relying on Google. Probably didn't enter the right phrase.)

Yeah, I wanted to see if I could find a possible solution for posix_spawn for when it will become necessary in some future version of Firefox/TFF. If it's currently fixed why break it again right?

So wait, Mozilla is using OS9-era code in Firefox 5? That's funny and cool.

 

ClassicHasClass

Well-known member
There's still some small globs of Carbon code in it, but they're removing it as they find it. Steve-O wants a hot, brown, Cocoa world.

 

PowerPup

Well-known member
Very happy with TFF5 on my PowerBook G4. :D Thanks to all who helped make TenFourFox 5 possible!

I was wondering, on TFF's homepage you mentioned the new Altivec optimizations for Webm and stuff, and in the future images and html. I noticed that Theora wasn't mentioned, is there already some Altivec optimization in place for it? Or might that be something to consider in the future?

Anyway, having a blast running a modern browser on 10 year old technology. :cool:

 

theos911

Well-known member
Altivec optimization
I read through the blog: I wasn't aware of Wintel's Altivec equivalent. However, I find it ironic that it is sooo close that it is (from what I managed to gleam) rather easy to port to PPC and Altivec. It is even more ironic how Wintel's is half as good as 8 year old Altivec (64 vs 128 data lines).

 

ClassicHasClass

Well-known member
WebM had an easier path because Google had already written an AltiVec decoder that no one was using. Like the nanojit, it was just a matter of dusting it off, finishing it up and polishing it.

The libtheora in 4/5 does have some hooks for SIMD, but they would have to be written from scratch, and it does not appear to accelerate its own YUV->RGB conversion, whereas we have almost all of these pieces together for WebM already. I'm working on squeezing out more bandwidth from the YCbCr->RGB conversion that WebM uses, which right now is a naive conversion of the MMX routines and wastes about half the vector bandwidth, but this is a solved problem. Playback is a lot better on G5, nearly perfect on quads, and significantly improved on 7450. Even 7400 Macs can at least play the audio even if the video is a slideshow. WebM has come a long way since TenFourFox 4.0.

More to the point, and this might be just the circles I run in, Theora seems stillborn as a format to me. VP3 compresses worse than VP8 and doesn't really have any content weight behind it; most web video seems to be either H.264 or WebM. It would be a lot more work to get libtheora AltiVec-converted and I'd have to have assurances there would be a payoff, since (let's be honest here) I'd be doing most of the work myself. Unless you have a patch ;D

However, I find it ironic that it is sooo close that it is (from what I managed to gleam) rather easy to port to PPC and Altivec. It is even more ironic how Wintel's is half as good as 8 year old Altivec (64 vs 128 data lines).
I'm no Intel arch god, but here's how x86 SIMD breaks down. Intel gives you now three major choices: MMX, the original x86 SIMD; SSE; or SSE2 and successors. (There are actually others, but these three are the most widely used and available.)

MMX aliased FP registers into 64-bit SIMD "MMX" registers, which was a blessing in that the operating system needed no special support to save registers in context switches (so it was instantly compatible), but a curse in that it was integer only and you lost your floating point registers temporarily. Every CPU from the Pentium MMX and Pentium II on has MMX, so there is a lot of MMX code out there. MMX code is hard to translate to AltiVec because it only deals in 64-bit quantities and is typically only aligned to 64-bit quantities, and AltiVec performs significantly worse with misalignment. The current YCbCr->RGB code, because it is descended from MMX code, is only doing 64 bits at once and has some ugly gyrations to deal with alignment. I'm rewriting it, now that I know it works and already is beneficial, to grab two "MMX" operations at once and smush them together into one big vector, saving some steps.

SSE adds new 128-bit XMM registers which are the same size as the AltiVec 128-bit vector registers, but can only deal with them as 4 32-bit floating point quantities. However, AltiVec can do this too, so SSE code translates pretty easily to AltiVec. Strict FP usage isn't generally useful, however, so there isn't much pure SSE code unfortunately.

Most new code is SSE2 and successors. SSE2 adds pretty much all the other data types to the 128-bit XMM vectors, including byte, short and word, and one that AltiVec does not have, 2 64-bit doubles (but this usage is pretty rare so far). SSE2 code is a bit harder to translate to AltiVec than SSE because SSE2 is not as picky about misalignment and the AltiVec C intrinsics require strict typing or a lot of casts, where it is a common idiom in SSE2 code to just treat the vector as a blob and sling it around transparently from type to type. But, again, strict typing saves you from stupid mistakes, so choose your poison. SSE3, SSSE3 and SSE4 just add more instructions.

SSE2 is a lot more comparable to AltiVec than SSE or MMX, but AltiVec still has some great features SSE2 doesn't have. In particular, AltiVec's permute unit makes it possible to turn certain kinds of swapping and reordering operations into a single instruction which runs very quickly. I use permutes to instantly deal with endian swaps. And most important of all, there are lot more AltiVec vector registers than SSE2 XMM registers, even if the x86 chip is in 64-bit mode.

AltiVec is remarkable technology and of course yet another wonderful thing about the PowerPC that never achieved its full potential.

 
Top