13 ms·

Apple's long processor journey

162 points by AndrewDucker 7y ago

classichasclass 7y ago
This is a little unfair. Yes, the notionally "normal" state of the system, at least from the view of the nanokernel, is to be running 68K code. However, by the days of 8.5, most of the OS was native, with the remaining legacy being all those obnoxious UPPs. In fact, porting the classic Mac OS to PowerPC by then was actually the low-effort move while Apple management scrounged around to figure out what to do after the demise of Copland.
- lproven 7y ago
  Hi. Original blog post author here. Not really, no. I was there and used and supported these machines throughout. There was a CDEV available at the time. I can't find it any more. It placed an "indicator light" in your menu bar, which glowed red when the OS was executing 68K code and green for PowerPC code. I installed it on all the machines I could. It sat there red 99% of the time. Occasionally it flashed green briefly. Only a very few very-CPU-intensive apps made it stay green: applying large Photoshop filters, for example. Even by MacOS 9.2.2 in my normal usage, browsing the web, doing email and spreadsheets and chat, and writing, it stayed red most of the time. PowerPC-native browsers such as WAMCOM call OS code all the time, and the OS code mostly stayed 68K. As for it being the low-effort move, I specifically addressed this point.
  - classichasclass 7y ago
    I don't know what CDEV you're referring to, but what it's observing sounds like a distortion. Every UPP call into the OS looks like 68K code. This enables 68K apps to "just do it." There was always some sort of thunk to handle registers and calling convention, but by 8.5 and certainly by 9 the code on the other side was usually native. Certainly some calls were still 68K. That's why almost every OS call still needed to go through that song and dance. If all the CDEV did was see the border at the Mixed Mode Manager switch, the machine would indeed appear to be running 68K code most of the time except for those few generally non-UI PPC-specific APIs, even though it isn't (and I challenge you to spend a little time in MacsBug and see that this is true).
throwaway3157 7y ago
I was thinking today that we need more computer archeology, and then I read this short post on macOS & professor history I was unaware of. We need more of this!
- dcolkitt 7y ago
  David Friedman has an interesting book Legal Systems Very Different From Our Own. It's basically what it sounds like, a survey of legal systems from distant past and foreign civilization that evolved in very separate conditions from what we know. I think, it'd be interesting if a technically minded person wrote an equivalent work Computer Systems Very Different From Our Own. By necessity most of it would probably be confined to retro-computing. But I think it'd be a pretty worthwhile endeavor. Not because those computers are likely to be better designed than our current systems. If anything quite the opposite. Like Friedman's legal systems, most of them probably have glaring pitfalls relative to modern state of the art. But it's a useful exercise to think about very distant points in the design space, and how and why those decisions were made. Even if the comparison point is clearly inferior, by virtue of being very exotic it helps us better understand the tradeoffs we make in our everyday incremental designs.
  - senderista 7y ago
    Like ternary architectures? https://en.m.wikipedia.org/wiki/Setun https://en.m.wikipedia.org/wiki/Setun
- lproven 7y ago
  Article author here. Thanks! I do quite a bit... https://news.ycombinator.com/item?id=22265615 https://news.ycombinator.com/item?id=22265615 This talk was 2y earlier: https://liam-on-linux.livejournal.com/56835.html https://liam-on-linux.livejournal.com/56835.html
Brave-Steak 7y ago
What was the reasoning for transitioning from Pascal to C?
- Dalrymple 7y ago
  Pure Pascal is not really suitable as an operating system implementation language. The obvious design choices are to: 1. Transition to C completely. 2. Extend Pascal (like HP did - HP called their resulting language MODCAL). 3. Support in-line C code in the Pascal compiler. 4. Support in-line assembly in the Pascal compiler. For superior library support and other reasons, Apple made the right choice here.
  - eschaton 7y ago
    Pascal as used on the Apple II, III, Lisa, Mac, and IIgs had the minimal extensions needed to be a systems language and was pretty much isomorphic to C. The “switch” from Pascal to C in the Mac market was less a “switch” and more a change in preference by developers—you could use either language and line by line your code would be equivalent. And the switch at Apple was likely just following the market. The APIs themselves used a language independent calling convention—arguments passed in CPU registers, not the stack, and system calls invoked by invalid opcodes in the 0xA000–0xAFFF range, not by JSR to a function pointer—so neither Pascal nor C really had an “advantage.”
  - lproven 7y ago
    Hi. Article author here. Pascal isn't ideal, but it has derivatives which are. Pascal became Modula-2, in which several large-scale OS implementation efforts were made, including Acorn ARX. Modula-2 became Oberon, which is an OS: https://news.ycombinator.com/item?id=15753138 https://news.ycombinator.com/item?id=15753138 There is also Euclid, which was used to implement a Unix. Yes, a Unix in Pascal. https://en.wikipedia.org/wiki/TUNIS https://en.wikipedia.org/wiki/TUNIS
trimbo 7y ago
I know this is about Mac's transitions and call me sentimental but I'm a little sad there was no mention of the 6502 and 65816.
- jdswain 7y ago
  And quite a bit of MacOS was ported back to the IIgs, most notably QuickDraw. The IIgs had ADB before the Mac, and colour QuickDraw years before the Mac had colour graphics. At the time it looks like the 65816 was deliberately speed limited so as to not overshadow the Mac. Mac was 8MHz, IIgs was 2.8MHz, the 65816 eventually got to 14MHz+, if Apple released an 8MHz IIgs it would have compared very well against the Mac. Woz is even quoted as saying that. Also, the Mac IIfx had two 10MHz 6502 based I/O processors to offload work from the main CPU.
  - duskwuff 7y ago
    > The IIgs had ADB before the Mac Marginally. The IIgs was released in September 1986; the Macintosh SE and II (which were the first Macs to support ADB) came out in March 1987. The 65C816 eventually made it up to 14 MHz, but I'm not sure those speed ratings were available in 1986. Even when they did, integrating them into the IIgs took some significant effort by accelerator manufacturers. > if Apple released an 8MHz IIgs it would have compared very well against the Mac. Woz is even quoted as saying that. Perhaps against an 8 MHz 68000 -- even then, the 16-bit data bus, 32-bit registers, and hardware multiply/divide on the 68000 would have made it stiff competition for the 65C816, which still used an 8-bit data bus, 16-bit registers, and supported no arithmetic operations more complex than addition, subtraction, and comparison. Against the later 680x0 parts, there'd have been no contest.
  - cable2600 7y ago
    Originally the Macintosh was going to be 6809 based, but Steve Jobs wanted more power and went with the 68000 series. GEOS was available on the Apple //e and Commodore 64 showing that even entry level CPUs that are 8 bit can do a GUI.
- lproven 7y ago
  Hi. Author of the piece here. The reason I skipped it is addressed in an earlier comment: there was no code transition. The 65C816 ran 6502 code natively. Yes there was a bit of native code, but if Apple had run the CPU at full speed, and devoted real effort to the IIGS, it would have killed the Mac off. It is, sadly, for the best that they didn't. I speak as someone who never owned or used an Apple ][. I was born in Britain. When the Apple ][ was new, it cost as much as a car in Europe. My first and second computers were Sinclairs, and my 3rd was an Amstrad (who bought Sinclair). The Apple ][ may have been the first home computer under US$1000 but in the UK that was a very large amount of money. Sinclair made the first home computers for under GBP 100, a far more important cost barrier for us.
perl4ever 7y ago
BeOS seemed really nice at the time. I'm not sure if it would have worked out better in the long run, but it sounded great. I always had the sense that consumer focused computers should be engineered with real-time capabilities, and instead, they ended up being based on time-sharing systems which seems like it hampers UI and media processing. For decades, and especially presently, I get so frustrated with lags and hiccups no matter how fast the CPU and storage are.
- smallstepforman 7y ago
  Responding before the horde of Jobs fanboys claim the underlying OS didn’t matter. They like to forget that NeXT alone didn’t matter, nor did PowerPC Mac’s or the initial scroll wheel iPod’s all under Jobs stewardship. The company was saved by the following: - transition to x86, and Bootcamp fallback. - iPhone, with decent touch interface and native (non Java) API and open AppStore - iPad at right time. Without this trifecta, Apple would be extinct like SGI, Sun, and the others. BeOS was what the geeks wanted. It was modern, multi core, C++ based, and with the backing of a big company, would have seriously dominated the desktop computing landscape. I’d be willing to state that Apple would have had a bigger market share with BeOS rather than NeXT.
  - samatman 7y ago
    Apple was robustly profitable by 2003, when I purchased my first Mac running OS X and a third-generation iPod. They turned that corner in the beginning of 1998 in fact[0]. They sold 50 million iPods in 2007. [0]: https://www.cultofmac.com/461234/today-in-apple-history-apple-is-back-in-the-black/ https://www.cultofmac.com/461234/today-in-apple-history-appl... It wouldn't be a trillion-dollar business without the iPhone, sure. I've no reason to think it wouldn't still be in business, and you haven't given any. It's certainly possible that Apple would have thrived with a next-generation Mac based on BeOS. Personally, I wouldn't have switched; I was tired of dual-booting Yggdrasil Linux and Windows, and the prospect of buying a (relatively) affordable Unix workstation was exciting to someone who cut his teeth on SparcStations. I'm not the median customer, then or now, however. Back then she was probably in desktop publishing; BeOS would have been just fine.
therealmarv 7y ago
I hope to see AMD in this list soon. Apple is not using the best desktop and laptop processors nowadays.
- scarface74 7y ago
  The best laptop processor would be an Apple designed ARM chip.
  - arvinsim 7y ago
    You are basing that on what metrics? It's all just speculation for now. AMD 4000 mobile processors, on the other hand, already exist.
    - scarface74 7y ago
      We know the performance/power trade offs of Apple’s ARM chips in iPad Pros.
      - duskwuff 7y ago
        And the odds are good that even that could be scaled up further for a laptop-class part. The iPad Pro is a passively cooled device which is expected to always run on battery power, after all; a laptop would have larger batteries and more thermal margin. Not that it'd even have to be scaled up by much. The A13 (iPhone 11) already performs comparably to many Intel mobile parts; an -X variant (future iPad Pro) would surely improve upon that.
        zrm 7y ago
        The scaling is really the question. ARM processors generally have better performance per watt because they're designed to prioritize power efficiency over absolute performance. The Intel parts Apple's ARM processors compare to on performance are the lowest power ones, which isn't exactly the sweet spot for Intel's microarchitecture. If you gave the ARM designers the (higher) laptop power budget, almost certainly they'd increase performance at the expense of performance per watt. In other words they'd take more of the trade offs that Intel and AMD do. But to justify switching architectures it can't just be the same, it would have to be enough better to be worth the transition.
gok 7y ago
Perhaps better titled "the Mac's long journey", since it's only about one Apple platform and not really about processors. And even then it seems to end around 2006.
- lproven 7y ago
  Hi, original author here. Yes, I'm talking about Apple Macs, specifically. I am not aware of any other Apple product line that has transitioned from any one processor architecture to another different one while maintaining any form of software compatibility; are you? Non-computers don't matter. Nobody cares if a laser printer has the same CPU as the previous generation of laser printer, so long as it still prints and there's a driver. Nobody cares if a new iPod has a different CPU, because iPods didn't run apps. The iOS line has never made a CPU transition, so there's nothing to write about. It's ARM as it's always been. 32-bit to 64-bit is no big deal; I did a FOSDEM talk on this theme a fortnight ago: https://news.ycombinator.com/item?id=22265615 https://news.ycombinator.com/item?id=22265615 Only Apple's Mac made a journey like this, so there's nothing else to talk about. The Apple IIGS had a different CPU but was backwards-compatible; no transition involved. It ends around 2008 because by then Apple was making 64-bit dual-core x86 machines with 64-bit UEFI and they still are. That was their last transition so far. There's nothing more to say.
  - shaabanban 7y ago
    You could make the argument that they've made at least a partial transition since the 2008 64 bit UEFI with the whole T2 ARM co-processor thing.
    - chipotle_coyote 7y ago
      Mac software the way the original author is talking about it is still basically running like 64-bit Intel Mac software, though, right? Catalina is a transition of sorts in that it's dropping all 32-bit compatibility, so that could be a footnote, but I think that's about it -- until-slash-if Macs make the oft-rumored transition to Apple-designed ARM CPUs.
  - 7y ago
msoad 7y ago
I simply can’t scroll on this website Safari iOS
- gumby 7y ago
  I read it in reader mode, but I am on an ipad which perhaps has a different safari from the iphone.
deleted 7y ago
[deleted]
cable2600 7y ago
Didn't IBM have OS/2 Warp for PowerPC CHRP systems coming out that later turned into vaporware? It was supposed to use X86 emulation to run DOS, 16 bit Windows, and OS/2 programs on the PowerPC Macs. Don't forget Linux for PowerMacs. Apple once had MKLinux available.
- kylek 7y ago
  I cut my linux-teeth on PowerMacs. OS X was going to be based on unix, so I thought I'd get a jump start on this new fangled stuff (I was 11 -- "It's a UNIX system...I know this!"). I remember an issue of Mac Addict arrived with a copy of LinuxPPC and an app that, through something that felt like witchcraft at the time, would let you boot into linux directly from Mac OS. (Also, some random OS/2-powerpc history- https://www.os2museum.com/wp/os2-history/os2-warp-powerpc-edition/ https://www.os2museum.com/wp/os2-history/os2-warp-powerpc-ed... )
- ajdlinux 7y ago
  Upstream Linux continues to support Power Macs today.
- ThenAsNow 7y ago
  > Didn't IBM have OS/2 Warp for PowerPC CHRP systems coming out that later turned into vaporware? It was developed, and pre-release versions were available to developers, but the whole "Workplace OS" initiative and OS/2-PowerPC was killed when it was obvious it wasn't going to meet with commercial success. Memory is fuzzy as to the specific sequence of events, but it's of a piece with the Pink/Taligent failures as well. I also recall performance not being too great. By the time Warp 4 was released, I think the IBM Personal Systems/PC hardware business had already signed a major OEM deal with Microsoft for Windows 95 and NT. I know I saw at least one book sitting on a major retail bookstore shelf that was geared toward developers on the OS/2-PowerPC platform (sadly, after the platform was already dead). Some of us in the early 90s had big hopes for CHRP and PowerPC, outside of the Mac universe. In addition to the pretty good writeup at the link posted by kylek, some others (including CD images): https://archive.org/details/os2-powerpc https://archive.org/details/os2-powerpc http://www.edm2.com/index.php/OS/2_for_the_PowerPC:_The_Development_Environment http://www.edm2.com/index.php/OS/2_for_the_PowerPC:_The_Deve...
dehrmann 7y ago
As Apple's rumored to be eyeing ARM for Macs, how impractical is it to make a more power efficient x86 CPU (like an Atom 2), or is x86 the 737 of CPU architectures?
abelliqueux 7y ago
Full story on the transition from 68000 to powerpc : https://www.filfre.net/2020/02/the-deal-of-the-century-or-the-alliance-of-losers/ https://www.filfre.net/2020/02/the-deal-of-the-century-or-th...
- tambourine_man 7y ago
  That was one fine article. Thanks for the link.
kenips 7y ago
Thanks for this. It’s a great read. Looking for part II on more of OS X‘s evolution (64 bit, Intel, DriverKit, etc).

162 points by AndrewDucker 7y ago

This is a little unfair. Yes, the notionally "normal" state of the system, at least from the view of the nanokernel, is to be running 68K code. However, by the days of 8.5, most of the OS was native, with the remaining legacy being all those obnoxious UPPs. In fact, porting the classic Mac OS to PowerPC by then was actually the low-effort move while Apple management scrounged around to figure out what to do after the demise of Copland.

lproven 7y ago
Hi. Original blog post author here. Not really, no. I was there and used and supported these machines throughout. There was a CDEV available at the time. I can't find it any more. It placed an "indicator light" in your menu bar, which glowed red when the OS was executing 68K code and green for PowerPC code. I installed it on all the machines I could. It sat there red 99% of the time. Occasionally it flashed green briefly. Only a very few very-CPU-intensive apps made it stay green: applying large Photoshop filters, for example. Even by MacOS 9.2.2 in my normal usage, browsing the web, doing email and spreadsheets and chat, and writing, it stayed red most of the time. PowerPC-native browsers such as WAMCOM call OS code all the time, and the OS code mostly stayed 68K. As for it being the low-effort move, I specifically addressed this point.
- classichasclass 7y ago
  I don't know what CDEV you're referring to, but what it's observing sounds like a distortion. Every UPP call into the OS looks like 68K code. This enables 68K apps to "just do it." There was always some sort of thunk to handle registers and calling convention, but by 8.5 and certainly by 9 the code on the other side was usually native. Certainly some calls were still 68K. That's why almost every OS call still needed to go through that song and dance. If all the CDEV did was see the border at the Mixed Mode Manager switch, the machine would indeed appear to be running 68K code most of the time except for those few generally non-UI PPC-specific APIs, even though it isn't (and I challenge you to spend a little time in MacsBug and see that this is true).

throwaway3157 7y ago

I was thinking today that we need more computer archeology, and then I read this short post on macOS & professor history I was unaware of. We need more of this!

dcolkitt 7y ago
David Friedman has an interesting book Legal Systems Very Different From Our Own. It's basically what it sounds like, a survey of legal systems from distant past and foreign civilization that evolved in very separate conditions from what we know. I think, it'd be interesting if a technically minded person wrote an equivalent work Computer Systems Very Different From Our Own. By necessity most of it would probably be confined to retro-computing. But I think it'd be a pretty worthwhile endeavor. Not because those computers are likely to be better designed than our current systems. If anything quite the opposite. Like Friedman's legal systems, most of them probably have glaring pitfalls relative to modern state of the art. But it's a useful exercise to think about very distant points in the design space, and how and why those decisions were made. Even if the comparison point is clearly inferior, by virtue of being very exotic it helps us better understand the tradeoffs we make in our everyday incremental designs.
- senderista 7y ago
  Like ternary architectures? https://en.m.wikipedia.org/wiki/Setun https://en.m.wikipedia.org/wiki/Setun
lproven 7y ago
Article author here. Thanks! I do quite a bit... https://news.ycombinator.com/item?id=22265615 https://news.ycombinator.com/item?id=22265615 This talk was 2y earlier: https://liam-on-linux.livejournal.com/56835.html https://liam-on-linux.livejournal.com/56835.html

Brave-Steak 7y ago

What was the reasoning for transitioning from Pascal to C?

Dalrymple 7y ago
Pure Pascal is not really suitable as an operating system implementation language. The obvious design choices are to: 1. Transition to C completely. 2. Extend Pascal (like HP did - HP called their resulting language MODCAL). 3. Support in-line C code in the Pascal compiler. 4. Support in-line assembly in the Pascal compiler. For superior library support and other reasons, Apple made the right choice here.
- eschaton 7y ago
  Pascal as used on the Apple II, III, Lisa, Mac, and IIgs had the minimal extensions needed to be a systems language and was pretty much isomorphic to C. The “switch” from Pascal to C in the Mac market was less a “switch” and more a change in preference by developers—you could use either language and line by line your code would be equivalent. And the switch at Apple was likely just following the market. The APIs themselves used a language independent calling convention—arguments passed in CPU registers, not the stack, and system calls invoked by invalid opcodes in the 0xA000–0xAFFF range, not by JSR to a function pointer—so neither Pascal nor C really had an “advantage.”
- lproven 7y ago
  Hi. Article author here. Pascal isn't ideal, but it has derivatives which are. Pascal became Modula-2, in which several large-scale OS implementation efforts were made, including Acorn ARX. Modula-2 became Oberon, which is an OS: https://news.ycombinator.com/item?id=15753138 https://news.ycombinator.com/item?id=15753138 There is also Euclid, which was used to implement a Unix. Yes, a Unix in Pascal. https://en.wikipedia.org/wiki/TUNIS https://en.wikipedia.org/wiki/TUNIS

trimbo 7y ago

I know this is about Mac's transitions and call me sentimental but I'm a little sad there was no mention of the 6502 and 65816.

jdswain 7y ago
And quite a bit of MacOS was ported back to the IIgs, most notably QuickDraw. The IIgs had ADB before the Mac, and colour QuickDraw years before the Mac had colour graphics. At the time it looks like the 65816 was deliberately speed limited so as to not overshadow the Mac. Mac was 8MHz, IIgs was 2.8MHz, the 65816 eventually got to 14MHz+, if Apple released an 8MHz IIgs it would have compared very well against the Mac. Woz is even quoted as saying that. Also, the Mac IIfx had two 10MHz 6502 based I/O processors to offload work from the main CPU.
- duskwuff 7y ago
  > The IIgs had ADB before the Mac Marginally. The IIgs was released in September 1986; the Macintosh SE and II (which were the first Macs to support ADB) came out in March 1987. The 65C816 eventually made it up to 14 MHz, but I'm not sure those speed ratings were available in 1986. Even when they did, integrating them into the IIgs took some significant effort by accelerator manufacturers. > if Apple released an 8MHz IIgs it would have compared very well against the Mac. Woz is even quoted as saying that. Perhaps against an 8 MHz 68000 -- even then, the 16-bit data bus, 32-bit registers, and hardware multiply/divide on the 68000 would have made it stiff competition for the 65C816, which still used an 8-bit data bus, 16-bit registers, and supported no arithmetic operations more complex than addition, subtraction, and comparison. Against the later 680x0 parts, there'd have been no contest.
- cable2600 7y ago
  Originally the Macintosh was going to be 6809 based, but Steve Jobs wanted more power and went with the 68000 series. GEOS was available on the Apple //e and Commodore 64 showing that even entry level CPUs that are 8 bit can do a GUI.
lproven 7y ago
Hi. Author of the piece here. The reason I skipped it is addressed in an earlier comment: there was no code transition. The 65C816 ran 6502 code natively. Yes there was a bit of native code, but if Apple had run the CPU at full speed, and devoted real effort to the IIGS, it would have killed the Mac off. It is, sadly, for the best that they didn't. I speak as someone who never owned or used an Apple ][. I was born in Britain. When the Apple ][ was new, it cost as much as a car in Europe. My first and second computers were Sinclairs, and my 3rd was an Amstrad (who bought Sinclair). The Apple ][ may have been the first home computer under US$1000 but in the UK that was a very large amount of money. Sinclair made the first home computers for under GBP 100, a far more important cost barrier for us.

perl4ever 7y ago

BeOS seemed really nice at the time. I'm not sure if it would have worked out better in the long run, but it sounded great. I always had the sense that consumer focused computers should be engineered with real-time capabilities, and instead, they ended up being based on time-sharing systems which seems like it hampers UI and media processing. For decades, and especially presently, I get so frustrated with lags and hiccups no matter how fast the CPU and storage are.

smallstepforman 7y ago
Responding before the horde of Jobs fanboys claim the underlying OS didn’t matter. They like to forget that NeXT alone didn’t matter, nor did PowerPC Mac’s or the initial scroll wheel iPod’s all under Jobs stewardship. The company was saved by the following: - transition to x86, and Bootcamp fallback. - iPhone, with decent touch interface and native (non Java) API and open AppStore - iPad at right time. Without this trifecta, Apple would be extinct like SGI, Sun, and the others. BeOS was what the geeks wanted. It was modern, multi core, C++ based, and with the backing of a big company, would have seriously dominated the desktop computing landscape. I’d be willing to state that Apple would have had a bigger market share with BeOS rather than NeXT.
- samatman 7y ago
  Apple was robustly profitable by 2003, when I purchased my first Mac running OS X and a third-generation iPod. They turned that corner in the beginning of 1998 in fact[0]. They sold 50 million iPods in 2007. [0]: https://www.cultofmac.com/461234/today-in-apple-history-apple-is-back-in-the-black/ https://www.cultofmac.com/461234/today-in-apple-history-appl... It wouldn't be a trillion-dollar business without the iPhone, sure. I've no reason to think it wouldn't still be in business, and you haven't given any. It's certainly possible that Apple would have thrived with a next-generation Mac based on BeOS. Personally, I wouldn't have switched; I was tired of dual-booting Yggdrasil Linux and Windows, and the prospect of buying a (relatively) affordable Unix workstation was exciting to someone who cut his teeth on SparcStations. I'm not the median customer, then or now, however. Back then she was probably in desktop publishing; BeOS would have been just fine.

therealmarv 7y ago

I hope to see AMD in this list soon. Apple is not using the best desktop and laptop processors nowadays.

scarface74 7y ago
The best laptop processor would be an Apple designed ARM chip.
- arvinsim 7y ago
  You are basing that on what metrics? It's all just speculation for now. AMD 4000 mobile processors, on the other hand, already exist.
  - scarface74 7y ago
    We know the performance/power trade offs of Apple’s ARM chips in iPad Pros.
    - duskwuff 7y ago
      And the odds are good that even that could be scaled up further for a laptop-class part. The iPad Pro is a passively cooled device which is expected to always run on battery power, after all; a laptop would have larger batteries and more thermal margin. Not that it'd even have to be scaled up by much. The A13 (iPhone 11) already performs comparably to many Intel mobile parts; an -X variant (future iPad Pro) would surely improve upon that.
      - zrm 7y ago
        The scaling is really the question. ARM processors generally have better performance per watt because they're designed to prioritize power efficiency over absolute performance. The Intel parts Apple's ARM processors compare to on performance are the lowest power ones, which isn't exactly the sweet spot for Intel's microarchitecture. If you gave the ARM designers the (higher) laptop power budget, almost certainly they'd increase performance at the expense of performance per watt. In other words they'd take more of the trade offs that Intel and AMD do. But to justify switching architectures it can't just be the same, it would have to be enough better to be worth the transition.

gok 7y ago

Perhaps better titled "the Mac's long journey", since it's only about one Apple platform and not really about processors. And even then it seems to end around 2006.

lproven 7y ago
Hi, original author here. Yes, I'm talking about Apple Macs, specifically. I am not aware of any other Apple product line that has transitioned from any one processor architecture to another different one while maintaining any form of software compatibility; are you? Non-computers don't matter. Nobody cares if a laser printer has the same CPU as the previous generation of laser printer, so long as it still prints and there's a driver. Nobody cares if a new iPod has a different CPU, because iPods didn't run apps. The iOS line has never made a CPU transition, so there's nothing to write about. It's ARM as it's always been. 32-bit to 64-bit is no big deal; I did a FOSDEM talk on this theme a fortnight ago: https://news.ycombinator.com/item?id=22265615 https://news.ycombinator.com/item?id=22265615 Only Apple's Mac made a journey like this, so there's nothing else to talk about. The Apple IIGS had a different CPU but was backwards-compatible; no transition involved. It ends around 2008 because by then Apple was making 64-bit dual-core x86 machines with 64-bit UEFI and they still are. That was their last transition so far. There's nothing more to say.
- shaabanban 7y ago
  You could make the argument that they've made at least a partial transition since the 2008 64 bit UEFI with the whole T2 ARM co-processor thing.
  - chipotle_coyote 7y ago
    Mac software the way the original author is talking about it is still basically running like 64-bit Intel Mac software, though, right? Catalina is a transition of sorts in that it's dropping all 32-bit compatibility, so that could be a footnote, but I think that's about it -- until-slash-if Macs make the oft-rumored transition to Apple-designed ARM CPUs.
- 7y ago

msoad 7y ago

I simply can’t scroll on this website Safari iOS

gumby 7y ago
I read it in reader mode, but I am on an ipad which perhaps has a different safari from the iphone.

deleted 7y ago

[deleted]

cable2600 7y ago

Didn't IBM have OS/2 Warp for PowerPC CHRP systems coming out that later turned into vaporware? It was supposed to use X86 emulation to run DOS, 16 bit Windows, and OS/2 programs on the PowerPC Macs. Don't forget Linux for PowerMacs. Apple once had MKLinux available.

kylek 7y ago
I cut my linux-teeth on PowerMacs. OS X was going to be based on unix, so I thought I'd get a jump start on this new fangled stuff (I was 11 -- "It's a UNIX system...I know this!"). I remember an issue of Mac Addict arrived with a copy of LinuxPPC and an app that, through something that felt like witchcraft at the time, would let you boot into linux directly from Mac OS. (Also, some random OS/2-powerpc history- https://www.os2museum.com/wp/os2-history/os2-warp-powerpc-edition/ https://www.os2museum.com/wp/os2-history/os2-warp-powerpc-ed... )
ajdlinux 7y ago
Upstream Linux continues to support Power Macs today.
ThenAsNow 7y ago
> Didn't IBM have OS/2 Warp for PowerPC CHRP systems coming out that later turned into vaporware? It was developed, and pre-release versions were available to developers, but the whole "Workplace OS" initiative and OS/2-PowerPC was killed when it was obvious it wasn't going to meet with commercial success. Memory is fuzzy as to the specific sequence of events, but it's of a piece with the Pink/Taligent failures as well. I also recall performance not being too great. By the time Warp 4 was released, I think the IBM Personal Systems/PC hardware business had already signed a major OEM deal with Microsoft for Windows 95 and NT. I know I saw at least one book sitting on a major retail bookstore shelf that was geared toward developers on the OS/2-PowerPC platform (sadly, after the platform was already dead). Some of us in the early 90s had big hopes for CHRP and PowerPC, outside of the Mac universe. In addition to the pretty good writeup at the link posted by kylek, some others (including CD images): https://archive.org/details/os2-powerpc https://archive.org/details/os2-powerpc http://www.edm2.com/index.php/OS/2_for_the_PowerPC:_The_Development_Environment http://www.edm2.com/index.php/OS/2_for_the_PowerPC:_The_Deve...

dehrmann 7y ago

As Apple's rumored to be eyeing ARM for Macs, how impractical is it to make a more power efficient x86 CPU (like an Atom 2), or is x86 the 737 of CPU architectures?

abelliqueux 7y ago

Full story on the transition from 68000 to powerpc : https://www.filfre.net/2020/02/the-deal-of-the-century-or-the-alliance-of-losers/ https://www.filfre.net/2020/02/the-deal-of-the-century-or-th...

tambourine_man 7y ago
That was one fine article. Thanks for the link.

kenips 7y ago

Thanks for this. It’s a great read. Looking for part II on more of OS X‘s evolution (64 bit, Intel, DriverKit, etc).