I don't have a clear direction for FPR25. As I said, a lot of the low hanging fruit is already picked, and some of the bigger projects are probably too big for a single developer trying to keep up with monthly releases (and do not lend themselves well to progressive implementation). I'll do some pondering in the meantime.
Saturday, June 27, 2020
Wednesday, June 24, 2020
But it's actually more amazing than that because you can have multiple subtypes. Besides generic PPC or PPC64, you can have binaries that run specifically on the G3 (ppc750), G4 (ppc7400 or ppc7450) or G5 (ppc970). The G5 subtype in particular can be 32-bit or 64-bit. I know this is possible because LAMEVMX is already a three-headed binary that selects the non-SIMD G3, AltiVec G4 or special superduper AltiVec G5 version at runtime from a single file. The main reason I don't do this in TenFourFox is that the resulting executable would be ginormous (as in over 500MB in size).
But ARM has an even more dizzying array of subtypes, at least nine, and the Apple ARM in the new AARM Macs will probably be a special subtype of its own. This means that theoretically a Super Duper Universal Binary ("SDUB") could have all of the following:
- ppc970 (this would work for both 32-bit and 64-bit on the G5)
- x86_64h (i.e., Haswell, here's an example, thanks Markus Stange for pointing this out)
- whatever AARM Macs turn out to be
Monday, June 22, 2020
But there's no doubt that Apple's upcoming move to ARM across all its platforms, or at least Apple's version of ARM (let's call it AARM), makes supreme business sense. And ARM being the most common RISC-descended architecture on the planet right now, it's a bittersweet moment for us Power Mac luddites (the other white meat) to see the Reality Distortion Field reject, embrace and then reject x86 once again.
Will AARM benefit Apple? You bet it will. Apple still lives in the shadow of Steve Jobs who always wanted the Mac to be an appliance, and now that Apple controls almost all of the hardware down to the silicon, there's no reason they won't do so. There's certainly benefit to the consumer: Big Sur is going to run really well on AARM because Apple can do whatever hardware tweaks, add whatever special instructions, you name it, to make the one OS the new AARM systems will run as fast and energy-efficient as possible (ironically done with talent from P. A. Semi, who was a Power ISA licensee before Apple bought them out). In fact, it may be the only OS they'll be allowed to run, because you can bet the T2 chip will be doing more and more essential tasks as application-specific hardware adds new functionality where Moore's law has failed. But the biggest win is for Apple themselves, who are no longer hobbled by Intel or IBM's respective roadmaps, and because their hardware will be sui generis will confound any of the attempts at direct (dare I say apples to apples) performance comparisons that doomed them in the past. AARM Macs will be the best machines in their class because nothing else will be in their class.
There's the darker side, too. With things like Gatekeeper, notarization and System Integrity Protection Apple has made it clear they don't want you screwing around with their computers. But the emergence of AARM platforms means Apple doesn't have to keep having the OS itself slap your hand: now the development tools and hardware can do it as well. The possibilities for low-level enforcement of system "security" policies are pretty much limitless if you even control the design of the CPU.
I might actually pick up a low-end one to play with, since I'm sort of a man without a portable platform now that my daily driver is a POWER9 (I have a MacBook Air which I tolerate because battery life, but Mojave Forever, and I'll bet runtime on these machines will be stupendous). However, the part that's the hardest to digest is that the AARM Mac, its hardware philosophy being completely unlike its immediate predecessors, is likely to be more Mac-like than any Mac that came before it save the Compact Macs. After all, remember that Jobs always wanted the Mac to be an appliance. Now, Tim Cook's going to sell you one.
Thursday, June 18, 2020
Thursday, June 11, 2020
Ken's patches have also been incorporated into the tree along with a workaround submitted by Raphaël Guay to deal with Twitch overflowing our JIT stack. This is probably due to something we don't support causing infinite function call recursion since with the JIT disabled it correctly just runs out of stack and stops. There is no way to increase stack further since we are strictly 32-bit builds and the stack already consumes 1GB of our 2.2-ish GB available, so we need to a) figure out why the stack overflow happens without being detected and b) temporarily disable that script until we do. It's part B that is implemented as a second blacklist which is on unless disabled, since other sites may do this, until we find a better solution to part A. This will be in FPR24 along with probably some work on MP3 compliance issues since TenFourFox gets used as a simple little Internet radio a lot more than I realized, and a few other odds and ends.
In case you missed it, I am now posting content I used to post here as "And now for something completely different" over on a new separate blog christened Old Vintage Computing Research, or my Old VCR (previous posts will remain here indefinitely). Although it will necessarily have Power Mac content, it will also cover some of my other beloved older systems all in one place. Check out properly putting your old Mac to Terminal sleep (and waking it back up again), along with screenshots of the unscreenshotable, including grabs off the biggest computer Apple ever made, the Apple Network Server. REWIND a bit and PLAY.