> Fun aside: I’ve always assumed this is why Core Foundation exists—to provide a common interface between Carbon and Cocoa. I don’t actually have a citation for this, though.
I suddenly felt the old Amiga fanboi inside of me pop up... :-)
At one time, up to at least 1996 the fastest Mac for running Photoshop, was not a Macintosh at all, but an Amiga tricked out with a graphics card and a CPU upgraded from the standard 68020 or 68040 to Motorolas last entry in the 68k line, the 68060. (Roughly equivalent to a Pentium - a bit slower clock but slightly more powerful instructions.)
How could this be? Photoshop 4 used 68k instructions, and the fastest 68k based Mac was the Quadra with the 68040 CPU. The first PowerMac was released in 1994, but it had to emulate the 68k to run Photoshop, which had a serious performance hit. Once Photoshop was released for the PowerPC, this anomaly ended.
(And Photoshop on Windows must have been faster than both Amiga and Mac pretty much immediately, but if I recall correctly it wasn't as capable on Windows right then. Or maybe people used to working on Macs for magazines etc just weren't prepared to switch platforms on a whim.)
So, Amiga was the original Hackintosh. :-)
But the copyright situation was even thornier then - to start the emulator you'd have to copy ROM images from a real Mac, and the only legal way to do that was to buy a Mac.
(Not that anybody did that, they just copied the ROM onto a floppy.) I think the preferred emulator was Shapeshiter. It worked remarkably well because most Macintosh programs did not use any direct hardware access but used the Apple provided official APIs.
Another anomaly was that Amiga was dead as a commercial gaming target by then, and so did not receive a port of Doom - but you could run the Macintosh version of Doom:
Earlier, there was even an older Mac emulator for the Amiga which tried to go the legal route by having a little hardware board you could put Mac ROMs into. (And then of course people copied the original ROMs and put them on EPROMs.)
Edit:
the same CPU upgrade almost happened to 68030 based Macs:
Remarkable. Today the fastest Mac is also a hackintosh, so some things have not changed so much.
That said, the first PowerPC Macs shipped in March of 1994 and Photoshop 3.0 for Mac in November. While the application was not native, a number of the filters were, so depending on what you did, they could be faster. Photoshop 4.0 was indeed fully native (November 1996).
You'd have to go through a lot of hoops like LLVM, compiler, etc CPU support just to get a Mac OS app written in Swift visible on the screen on OS9. Very interesting technical read on CPU support, compiler support, no matter the usefulness.
It would be interesting to upstream the LLVM-related work. And I do wonder how much work would it take to support other PPC32-based platforms - not just Apple and BeOS but AmigaOne, GameCube/Wii, *NIX and WinNT 3.51/4.0 systems etc.
As for WinNT and other non-ELF platforms systems, that's retro hobbyist territory, not very likely to end up in upstream LLVM. But you could always convert object files into the right format externally! e.g. for years building TianoCore EDK2 on non-Windows has involved conversions from ELF to PE (now there's also a CLANGPDB setting that produces PEs directly from LLVM)
m68k seems to be mostly a hobbyist interest rather than a commercial interest at this point. The problem is, if the person whose hobby it is gets busy and then either the whole project is getting held up by that backend, or it just gets removed.
At least in case of PPC and System z, IBM has a commercial interest in making LLVM work for them – and the former has some hobbyist/retrocomputing benefits as an unplanned side-effect. (System z, much less so – modern System z is 64-bit, whereas most of the mainframe hobbyist community focus is on the legacy pre-1980s 24-bit architecture.)
m68k isn't just one person's hobby however - there's a sizeable retrocomputing community around it.
> and then either the whole project is getting held up by that backend, or it just gets removed.
LLVM has a notion of "experimental" backends that's precisely meant to avoid this. Unfortunately it's a bit misused at present, with backends that have little reason to be "experimental" being marked as such for historical reasons, while stuff like m68k (and perhaps this new PPC-based stuff) that could use it gets left out altogether. This should be fixed.
> m68k isn't just one person's hobby however - there's a sizeable retrocomputing community around it.
But how many people in that community have the skills to maintain the LLVM backend?
I agree it would be great if m68k made it in LLVM, I'm just trying to explain why the LLVM developers seem so hesitant about it.
A thought: if there is really enough interest in LLVM for m68k, those interested could set up a not-for-profit membership association with annual dues, and then the association could use those dues to hire a developer to work full-time (or even just part-time) on LLVM+m68k. I think if an arrangement like that existed, the LLVM development team would be far more likely to say "Yes". If 1000 people were all willing to pay $100/year to support this, that would make available $100,000 per annum to fund development.
IBM is doing most of the work wrt. this backend to support their AIX systems. Support for other platforms mostly comes along for the ride.
(For that matter, LLVM might well pick up a backend that has sufficient maintenance to keep up with internal code changes, regardless of "production" concerns. See RISC-V as an example - obviously it's not seeing a lot of production use, but LLVM does include it.)
Far from being useless, this sort of work could ultimately make it easier to preserve existing Classic Mac OS-based apps and code, and run them on modern systems. Just as having FreeDOS around and even in active development makes it easier to support the DosBox platform.
No, it does the opposite: it ensures that toolchains for the modern system work on retro systems. Which is a neat hack, but doesn’t help with preserving anything.
I recently have been getting into making a lot of small swift apps for personal use AND now have MacOS 7 and 8 running on my iPad since they’ve added mouse pointer support. Excited to dig into this article!
The first is more stable, and recently got the pointer support added, but doesn’t go up to MacOS 8 AFAIK. I copied a bit of the stuff from that to the MacEmu one to get the pointer working ok.
I don't know if this is the way, but ~20 years ago I was curious about running emulators for 68k Macs on PCs.. there was vMac which emulated black&white Mac Plus, and basilisk II which emulated a macII. They could both run system 7. That was true circa 1998. I imagine the hardware needs are not that high.
This post is obviously written with sarcasm. However, I've been enamoured with the G4 Cube and 12" PowerBooks since they first came out and haven't been able to find a device that's been as aesthetically pleasing since.
This may have something to do with those being as objects of desire from my youth.
> Fun aside: I’ve always assumed this is why Core Foundation exists—to provide a common interface between Carbon and Cocoa. I don’t actually have a citation for this, though.
This (very enjoyable) blog post from 2006 confirms it: https://ridiculousfish.com/blog/posts/bridge.html. I believe ridiculous_fish was working at Apple at the time.