Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
ARM-Intel-PPC universal binaries?
- Thread starter Wowfunhappy
- Start date
- Sort by reaction score
Yea, you can specifically compile for arch ppc which covers G3/G4/G5 (otherwise you’ll only compile for whatever processor your running) but you’ll get something along the lines of illegal instruction when running on a G3 if AltiVec is enabled.
PPCMC 7.1.6 is coming out later today, will have a G4/G5 only version and a G3/G4/G5 version.
Altivec only really matters when converting files for what PPCMC does however.
[automerge]1593092929[/automerge]
I can and do, everything in PPCMC is a universal G3-G4-G5 binary for 10.3.9. FFMPEG is as well, I just can’t turn on AltiVec optimizations in the compile or else you’ll get illegal instruction errors.
SDL is a program that has both AltiVec optimizations you can use and CPU runtime detection which means it does not have this problem, it’s smart enough not to run AltiVec code on G3’s. This isn’t an Apple issue it’s an FFMPEG implementation issue.
Last edited:
Oh, well.. once the ARM Macbook Pro comes out, will trade the 2015 for it. Hopefully, PPC will still be used.
Why couldn't you? The other guy specified altivec. Most altivec code is likely to be in the form of inline assembly or possibly intrinsics, which are usually preceded by reference code. You could compile both versions. You could compile with a runtime dispatcher. The altivec stuff really only applies to a small amount of your code. Any compiler auto-vectorized additions are really extraneous noise outside of key sections.
Compiling for x86 differs. They aren't ABI compatible.
I get it. I just wonder if you could use OS X's multi-arch format to more easily work around the problem. So just like with PPC/Intel, you'd make a single ffmpeg executable file which contains separate G3/G4/G5 binaries.
I'm assuming this doesn't work because otherwise TenFourFox would come as a "universal binary" instead of four seperate downloads optimized for individual machines, but let me know if that's mistaken! I have read that the whole multi-arch binary format dates back to NextStep, so you'd think it would be available...
Last edited:
AltiVec is not related to arch. Universal binaries have nothing to do with AltiVec.
AltiVec is special code that G4 and newer PowerPC can run to do things faster.
If you have AltiVec code, and run it on a G3, the G3 does not understand what to do. The executable can be made for G3/G4/G5 and it doesn’t matter because AltiVec is not backwards compatible with G3. It’s a hardware feature.
I see what you mean now, that could work. I’m so used to just compiling for all 3 in one binary.
I'm not sure what this multi-arch binary format really does.
You have basically 2 approaches that I know of for this kind of thing. Either you have a runtime dispatcher or you have dynamic linking of any code containing subroutines that may not be supported by all hardware targets. I don't know which one the multi-arch binary format falls under. If we're talking about Altivec, you're likely to see it large amounts over small sections of code, corresponding to expensive but parallelizable subroutines that meet the necessary data layout restrictions.
On the topic of ten four fox, if they're distributing different downloads, it's probably because it's easier and sometimes more performant to just recompile with different flags and inclusions. If they rely on including assembly as source, which some of these older performance critical things do for various reasons, then it may be the only practical means of distribution.
My understanding is that it's literally multiple copies of the same binary smushed together into a single file, with some header information of course. That's why there are tools to remove the PPC or Intel portions of a binary—you just delete those bytes and everything else still works fine. There's no magic.
I refer you to this blog entry ...
tenfourfox.blogspot.com
As magic as it sounds, do you really want a binary that is so fat?
The Super Duper Universal Binary
A question I got repeatedly the last couple days was, now that AARM (Apple ARM) is a thing, is the ultimate ARM-Intel-PowerPC Universal Bina...
tenfourfox.blogspot.com
As magic as it sounds, do you really want a binary that is so fat?
- ppc750
- ppc7400
- ppc7450
- ppc970 (this would work for both 32-bit and 64-bit on the G5)
- i386
- x86_64
- x86_64h (i.e., Haswell, here's an example, thanks Markus Stange for pointing this out)
- armv4t
- armv5
- armv6
- armv6m
- armv7
- armv7em
- armv7k
- armv7m
- armv7s
- whatever AARM Macs turn out to be
In that case, something like tenfourfox would need to replace multiple downloads with a larger one. That doesn't seem like an improvement.
I refer you to this blog entry ...
The Super Duper Universal Binary
A question I got repeatedly the last couple days was, now that AARM (Apple ARM) is a thing, is the ultimate ARM-Intel-PowerPC Universal Bina...
I just realized I never thanked you for linking me to this—thank you! Exactly what I was looking for.
Well, for starters, take out all the non-Apple-Silicon ARM variants. No version of Mac OS has ever run on those, so there's no point in including them.
So, would I want a 8-arch universal binary?
...yes, yes I think I would. Binaries aren't that large, disk space is relatively cheap, and it would be cool.
Apple is not known for being generous on disk space, so this sounds like a very bad idea.
I'd agree if we were talking about substantial amounts of disk space, but we aren't. We're talking about megabytes. I made this comment over on Hacker News:
https://news.ycombinator.com/item?id=23760572
I must've missed something in this thread or I haven't been paying attention to developments with Mac OS. Didn't backwards compatibility with PPC software officially end with Lion?
Appreciate that, Alex!
I must've missed something in this thread or I haven't been paying attention to developments with Mac OS. Didn't backwards compatibility with PPC software officially end with Lion?
Appreciate that, Alex!
PPC support ended with lion yes. But say you compile helloworld.c with the CFLAGS “-arch ppc -arch ppc64 -arch i386 -arch x86_64” using an old Xcode. You can run that file on Catalina and should be able to on any arm Mac using Rosetta 2. PPC is not supported, but if a supported arch is in the binary it will run.
Understood. Thanks for the explanation.
Anytime!
@Wowfunhappy you are in the credits for the next PPCMC update. Your a genius, no longer is two separate releases required for PPCMC.
This is so cool. It’s one single FFMPEG binary. When you run it on a G3 it looks like this
When you run on a G4 or G5 it looks like this
I don’t know of this ever being done before. PPCMC from scratch however now takes hours to compile since FFMPEG is compiled twice with different configuration options for G3 and G4 then lipo’d into one binary.
The only things changed between builds is -arch ppc750(G3) to -arch ppc7400(original G4) and —disable-altivec to —enable-altivec.
Last edited:
I refer you to this blog entry ...
The Super Duper Universal Binary
A question I got repeatedly the last couple days was, now that AARM (Apple ARM) is a thing, is the ultimate ARM-Intel-PowerPC Universal Bina...
As magic as it sounds, do you really want a binary that is so fat?
- ppc750
- ppc7400
- ppc7450
- ppc970 (this would work for both 32-bit and 64-bit on the G5)
- i386
- x86_64
- x86_64h (i.e., Haswell, here's an example, thanks Markus Stange for pointing this out)
- armv4t
- armv5
- armv6
- armv6m
- armv7
- armv7em
- armv7k
- armv7m
- armv7s
- whatever AARM Macs turn out to be
its actually missing one
there is a generic "ppc" arch with no CPU sub type its for example what Tiger uses when running on a PowerPC 604 CPU
and because TenForFox G3 is actually compiled for specifically PPC750 I cant actually run it on a 604 based tiger machine!
I should probably leave a comment on one of his blog posts about it, see if he can compile a PPC generic version (he did say in one of his blog posts that it should work!)
While we're discussing TenFourFox and Universal Binaries, I was wondering about this line in The Super Duper Universal Binary blog post:
As I was just saying, binaries are typically teeny tiny, so I was wondering how on earth TenFourFox could potentially be so large. Suffice to say, TenFourFox is not a normal app.
TenFourFox.app/Contents/MacOS contains five binaries, and a number of libraries. Most of these are expectedly tiny, but some are... very large. In particular, "XUL" is 73 MB. That is impressive.
It's not just TenFourFox either—my copy of Firefox 78 has the same XUL binary, and it's even larger at 124 MB.
I don't really know where I'm going with this, other than to say that browsers are crazy complicated.
As I was just saying, binaries are typically teeny tiny, so I was wondering how on earth TenFourFox could potentially be so large. Suffice to say, TenFourFox is not a normal app.
TenFourFox.app/Contents/MacOS contains five binaries, and a number of libraries. Most of these are expectedly tiny, but some are... very large. In particular, "XUL" is 73 MB. That is impressive.
It's not just TenFourFox either—my copy of Firefox 78 has the same XUL binary, and it's even larger at 124 MB.
I don't really know where I'm going with this, other than to say that browsers are crazy complicated.
Last edited:
If you really think about it, Web 3.0 is so resource hungry, and so intricately complex, it makes sense that Web browsers almost have to be mini operating systems in their own right just to access it properly. And this gets more and more true with each new iteration of Chrome or Firefox as time passes along.