Seems that'd be an argument for x86, not against it. Especially now when AMD is quite competitive.
> starting sometime around 2020
That prediction hasn't proven wrong yet, but it's looking increasingly unlikely. If the Mac were a bigger part of their revenues, they'd probably be further along in the transition though.
Already does but has are totally different. AMD could be ideally suited to ship an X86/ARM hybrid, run stuff on say 8 cores of ARM and say 2 cores of X86 for stuff that has compat problems.
It could happen, but I suspect this is a negotiating position more than a real desire to leave behind x86 in favor of Apple's ARM architecture chips. It makes more sense for them to improve the iPad Pro than to drop software compatibility across the MacBook lines.
For native apps sure. But my 6100/60 - the slowest PPC Mac - was slower in emulation than my LCII with a 68030-40Mhz accelerator. My computer was less than half the speed of the high end 040s at the time.
1. We haven’t yet seen what Apple's desktop-class chip can do.
2. Performance per watt is critical. Apple moved to Intel in large part because PowerPC couldn’t get this down, and one of the first two Intel Macs introduced was the MacBook Pro.
I dunno - an ARM version of the MacBook Air would be very appealing. I doubt that many MacBook Air users are running VMS (although the latest model supporting 16GB makes it more practical, it wouldn’t be my first choice) or Boot Camp. The vast majority of Mac Apps I use are in active development and I doubt there would be much lag before universal versions that also support ARM would be released.
Apple has done this twice before(68K and PPC), and currently runs a split CPU architecture ecosystem - granted there are hard product delineations between them today, but there aren’t any significant technical reasons why Apple couldn’t effectively support both ARM and Intel Macs - and do so for an indefinite period of time.
The MBA is a temporary aberration. The plan is to have that segment dominated by iPads. It's just taken a bit too long to figure out the right form factor (i.e. you really, really need a keyboard). I expect MBAs will eventually be dropped - again.
negotiating leverage is a nice side effect, but apple is serious about the move—the ipad pro is apple’s development platform for the switch to arm macs.
Intel is dying under the weight of its own technical debt. AMD will eventually have this problem too as ARM catches up.
Meanwhile, it's 2020 and and x86 instruction sets upgrades are infrequent compared to ARM. And x86 CPUs still are required to support 16-bit devices from 35 years ago.
> And x86 CPUs still are required to support 16-bit devices from 35 years ago.
I heard somewhere that this year Intel was going to begin to phase out support for BIOS, which would allow Intel to eliminate CPUs booting up in "real mode".
I think as long as plain PCI is something supported, some sort of 16-bit support has to be in the firmware because of option ROMs. Though I'm not sure UEFI couldn't service those with some sort of emulation layer (may as well, UEFI's already complex enough).
Closer to zero, it's an open architecture something the king of walled gardens wouldn't touch from a mile away. ;=)
Jokes aside the real reason why it's extremely unlikely is that they put a lot of money into ARM and they simply have no reason to switch to it. For this to happen ARM would need to do something like massively increase the price of their IP licenses, or simila. Which won't happen.
Apple has even a less incentive then most to support RISC-V versus ARM. They were a super early investor in ARM back in the early 90s (to the point where ARM probably wouldn't exist today without Apple). I'd be surprised if they pay more than a token amount for their core licenses.
For all intents and purposes, RISC-V being open just puts it on the same footing for Apple as ARM is for them.
RISC-V is basically a nonstarter. It has a lot of ridiculously goofy decisions in its ISA, it doesn't seem like competent CPU nor compiler engineers were ever in the loop for its design, and the number one benefit seems to be the licensing terms that make it super easy to extend or even replace 90% of the ISA while still calling it "RISC-V".
Sure. The most notable one I can think of is that integer multiplication is not in core. It's an extension. Anybody that's written a compiler or even stared at assembly would tell you how prevalent integer multiplication is, for any sort of loop or pointer addressing.
Even more baffling, is that the same extension that adds integer multiplication, also requires integer division, telling me that the spec authors think that multiplication and division are of the same circuit complexity, and used with the same frequency. And for one example for how goofy of an idea that is, ARM has never included integer division in its core ISA.
Then there's the whole JALR mess, which I don't know how to describe it other than "tech debt". Basically, they tried to simplify different kinds of jumps and returns into a single extension, by allowing any register to be used for the source and destination addresses. But for branch prediction reasons, and prefetching, you really do want to have a single link register, so the spec says "please don't use anything other than x1 as the link register, or you might not get proper performance".
> The most notable one I can think of is that integer multiplication is not in core. It's an extension. Anybody that's written a compiler or even stared at assembly would tell you how prevalent integer multiplication is, for any sort of loop or pointer addressing.
Those use cases work just fine with the shifts and adds trick you can do for multiply by constant. Honestly I was always baffled that ARMv6-M required a multiplier. Seemed to be the closest thing to an albatross over it's head, so much so that there were those M0's with an iterative, 32 cycle latency, bit serial multiplier.
> Even more baffling, is that the same extension that adds integer multiplication, also requires integer division, telling me that the spec authors think that multiplication and division are of the same circuit complexity, and used with the same frequency. And for one example for how goofy of an idea that is, ARM has never included integer division in its core ISA.
ARMv7-M (the closest ISA to Rv32-EM) requires integer divide.
> Then there's the whole JALR mess, which I don't know how to describe it other than "tech debt". Basically, they tried to simplify different kinds of jumps and returns into a single extension, by allowing any register to be used for the return address. But for branch prediction reasons, you really do want to have a single link register, so the spec says "please don't use anything other than x1 as the link register, or you might not get proper performance".
I don't really see this as a problem. For instance it neatly encodes unconditional jump without link as a jump with link to x0. Reminds me of some of the cute ways to encodes jumps from SH without being quite as ascetic.
> There's a lot more that I can go into.
Please do. Like totally unironically. I obviously have a pretty high opinion of RISC-V, but I appreciate someone who helps keep my biases in check.
> Even more baffling, is that the same extension that adds integer multiplication, also requires integer division, telling me that the spec authors think that multiplication and division are of the same circuit complexity
I was under the impression that cores with only a hardware multiplier could emulate the division instruction.
From the ISA specification[1]: "RV32I can emulate almost any other ISA extension".
> "please don't use anything other than x1 as the link register, or you might not get proper performance"
What's wrong with supporting a slow path? The alternative is to say x1 is always used, in which case you don't get the flexible, but more costly, alternative register variant, no?
> Anybody that's written a compiler or even stared at assembly would tell you how prevalent integer multiplication is, for any sort of loop or pointer addressing.
I think those transform to an integer multiplication…like never? They're almost always an offset to a base pointer that's incremented as you go through the loop…
> The most notable one I can think of is that integer multiplication is not in core.
And? Base RISC-V is meant to be as simple as possible; if you're designing an ultra-low power microcontroller you probably don't want a hardware multiplier, and you shouldn't be forced to have one. The "G" general purpose set of extensions is what you need for an application processor.
Something like RV64GC would be what most compiler writers would be targetting.
> telling me that the spec authors think that multiplication and division are of the same circuit complexity
Given the profiles of the spec authors I highly doubt this is the case; the number of modern cores which support hardware multiplication but not division is very small.
> Anybody that's written a compiler or even stared at assembly would tell you how prevalent integer multiplication is, for any sort of loop or pointer addressing.
For a loop you'll probably try to avoid as much multiplication as possible by transforming the induction variable to make it amenable to strength reduction.
Any ARM CPU that Apple uses in Macs will almost certainly be 64 bit A64 only - A64 is the only instruction set that has been supported on Apple SoC's since the A11 in 2017.
A64 is part of ARMv8 which was announced in October 2011 and was a brand new instruction set. It is not compatible with legacy 32 bit ARM applications and doesn't carry the relevant technical debt.
RISC-V was announced in 2010. It may have many admirable qualities but claiming that it has the advantage of a newer architecture is not correct in this context.
Incidentally, I think one of the remarkable features of ARM's recent commercial success - generally completely unremarked on - is how they have, relatively seamlessly, switched users from legacy 32 bit to an new 64 instruction set.
Many of the technical innovations from Intel over the past 5-10 years have been rolled back due to security or regression issues. TSX, SMT, AVX-512 just to name a few.
Another aspect of Intel not working that closely with Apple (it this ARM transition happens) is that Apple is often seen as knowing what they are talking about on deep technical issues (basically they have lots of really good engineers). So Intel will need to find other smart customers that they can work closely with to understand the consumers needs and what they should modify in their chips for the next gen.
Apple didn't switch processor vendors in the 90's. They dropped Motorola/PowerPC in the 00's in favor of Intel's Core processors that were remarkably faster and more power efficient.
Kind of. MacOS had a 68k emulator built in so that the entire OS (and application base) wouldn't have to be ported to PPC. I learned this recently when I disassembled Bolo (Stuart Cheshire, I'm trying to get ahold of you!) and found m68k instructions. Early Apple stuff is fascinating.
That was the later PowerPC -> Intel shift in the mid-2000s.
The switch from 68k to PowerPC was because PowerPC was an extremely powerful up-and-coming architecture at the time. A PowerMac 7100 (one of the earliest models) blew a 68040 Mac out of the water.
The switch from 68k to PowerPC was because 68k was dead, Motorola was pushing the 88k which was already failing in the market, and while Apple also considered other architectures like SPARC, they didn't want to be tied to only a single company's fortunes again like they were with the 68k.
So when IBM came to them asking "hey how about we scale down POWER to a desktop chip for you?" Apple also brought in Motorola so that they could dual-source their chips and not be dependent on one company, and PowerPC was born. Rather than being an up-and-coming competitor, PowerPC probably wouldn't exist without Apple's involvement (they would probably still have pursued a scaled-down POWER, but it wouldn't be PowerPC)
I guess I forgot about Apple and Intel in the 90s? I thought it was Motorola (68k) -> IBM Power PC -> Intel (present). What was the 90s Intel + Apple thing?
I would love an ARM based MacBook Air. I dunno why it’s widely assumed if Apple introduces one ARM based Mac that all Mac’s will eventually go ARM - Operating systems supporting multiple CPU architectures isn’t a new thing, and Apple has had more commercial success than anyone else. I have no doubt for me as an end user that once apps are updated I wouldn’t experience any difference - other than better performance, battery performance, and a cooler running computer.
Thankfully I’m not clinging to any older unsupported apps so I realize it’s easy for me to be pro ARM Mac - which is why I don’t expect Apple to go ARM only any time soon but offer a choice for quite a while while the market settles out.
And who knows, Intel could turn it around. They haven’t managed for the last 7 years or so, but I suppose it could still eventually happen.
> I dunno why it’s widely assumed if Apple introduces one ARM based Mac that all Mac’s will eventually go ARM
Two points to think about on this issue:
1) When Apple moved away from PowerPC, they did so entirely.
2) Apple historically* wanted to keep its hardware offerings simple and easy to understand, and supporting multiple architectures could muddy their offerings.
* When Jobs returned to Apple, he killed the confusing lineups in favor of one option each of desktop or mobile, for pros and home users. This has changed a bit lately, but I can imagine ARM and Intel options of Macbook vs Macbook Air vs Macbook Pro being a nonstarter.
Anyway, I agree, an ARM Macbook Air would be awesome, assuming the software followed suit.
I suspect that only going ARM on a few models could be detrimental. The risk is creating a niche within a niche. If they move everything, as with previous arch moves, it's "do or die" for third-parties.
But if, eg, MacBook Air turns into MacBook ARM but MacBook Pro remains Intel - this would be a very difficult schism. Many publishers might look at it as being pro customers staying on Intel and cost-sensitive customers on ARM, which could damage adoption.
The risk is having no carrot and no stick - not entirely dissimilar to Itanium's problem.
Apple's primary carrot and stick here will be the Mac App Store. Whether they split the product line between ARM and Intel, or go for a full transition to ARM, they'll mandate that apps on the App Store be universal binaries. The challenge as usual will be ISVs that don't distribute through the App Store and want to drag their heels (eg. Adobe, who always prefers ignoring Apple's roadmap in the hopes that they won't have to update their own code).
As I recall, Adobe was unwilling to abandon Carbon until Apple promised that Carbon wouldn't make the 64-bit transition. And even then, Adobe was pretty slow: Creative Suite on Windows started including 64-bit versions in 2008 and required a 64-bit CPU starting in 2010, but the last CS version for Mac in 2012 was still all 32-bit. When Apple dropped 32-bit support in 2019 after a two-year warning period, parts of Adobe Creative Cloud on macOS were still not ready.
Even Adobe's transition from PPC to Intel took 15 months after Intel Macs started shipping and 22 months after the x86 Mac dev kits were publicly announced (though I wouldn't be surprised if Adobe had a heads-up if not actual dev kits even before Apple publicly announced their Intel transition).
And let's not forget all the fuss Adobe made when the rest of the world was ready for Flash to die. This company has a history of being very defensive about their technical debt.
That doesn’t sound like a thing apple would do. The big reason to switch from intel to arm is not performance, it is two reasons: cost and control. Apple is no doubt getting a nice discount from intel, but they can make something with similar performance for a fraction of the cost. The new iphone se is faster than the macbook air, but it costs less than half. The cpu is a big part of that equation. In addition, apple is currently tied to intel’s roadmap, a situation which they surely want to end. Cost and control will drive them to switch the whole line-up.
I expect the transition to be done before the end of 2022, with intel support being dropped from the latest OS two years later, and no more macOS updates for intel-based macs two years after that.
There have been benchmarks showing that the A13 chip in the $400 iPhone SE is faster in single core performance than their 16 inch MacBook Pro. This is even with the thermal limits of a phone.
Worked just fine on my HP Omen 15 laptop and not for 4 hours but more like for a week and half non stop as I had to encode whole pile of 4K videos from pro format to consumer (h264). All the while I was also coding and debugging the application. I set TDP limiter so that the temp does not go above 80C that still has all 6 cores running at around 3GHz if I remember correctly. The fans were running non stop but not full throttle.
Not a thing what I would normally do but my rendering desktop was out of commission for a few days while waiting for parts to arrive.
Well, since we are talking about processor suitability for laptops, why wouldn’t having the higher thermal limits of a laptop compared to the phone allow the ARM chip to go “full throttle”.
Why would you love an ARM based MacBook Air versus, for example, a faster MacBook Air or one with more battery life? What makes ARM intrinsically better?
apple is moving on from intel because intel burned them badly with 10nm process chips. those were supposed to be out 5 years ago, when apple was readying the current design generation of macbook pros. apple finally had to give up hope and release the machine with hotter and less performant chips than they thought they’d be launching with.
that was the point that apple realized intel had become incapable of leading the industry any longer and started looking beyond intel.
There's some parallels with IBM dropping the ball on PowerPC, driving Apple to jump to Intel. The situation hasn't gotten quite as bad as it was with PowerPC, but Apple has seen this all before and wants to make the leap before it gets that bad, or at the very least open up an escape hatch or two (given Apple's relationship with AMD for graphics, I would be shocked if they haven't also talked about Ryzen in high end Macs).
Apple could just go for AMD, they have a really decent offering these days. Next to zero cost for external vendors as both are functionally equal, only a bit of cost for them to re-design their PCBs...
Obviously we'll be waiting a while before ARM hits high-end MacBook Pro and Mac Pro machines, what are the odds that Apple would retool to support AMD chips in that time?
I would love an AMD MBP. Intel's chips have rapidly diminishing value for pretty much all use cases and AMD is firing on all cylinders with Dr Lisa Su.
I'd like to see AMD as well, Ryzen is awesome bang for the buck. How would these perform in a laptop though since even the MacBook Air has overheating issues.
Given their penchant for keeping their touch interfaces (and software) separate from their non-touch, I'd imagine you'd get a full-fat macOS compiled for ARM. At this point, I'm sure they have internal builds of macOS on ARM that they've been toying with for years.
It just doesn't make sense to adapt iPadOS even more to a MacBook Air computer if they're not going to include a touchscreen. With them holding out as long as they have on touchscreens, I can't imagine them reversing course.
also, iOS is not, yet, ready to satisfy all of the use cases for Mac OS. It is possible to build an iOS laptop and some people would like that but it’s not going to cut it for a big number of their customers.
Apple had been letting Macs and Mac OS languish for a few years but has really stepped up their game over the last couple of years. I think they will keep them separate for a long time while brings things together under the hood.
Apple certainly has Mac OS ported for Arm and they also certainly have their own apps cross-compiled for Arm Mac OS. Once the OS and libraries are ported, the apps are relatively easy to adapt to the new system.
One thing that is ignored by the punditocracy is that a laptop has a lot of other silicon beyond the CPU.* Apple would have to have all the support chipset as well. Internal connections like memory controller etc they already have from iPhone/iPad, but Intel provides support for peripheral access. This works for the iPad, but note that the iPad Pro doesn't have laptop-class USB-C support much to the annoyance of some people. A laptop would have to, and probably would need USB4/TB4 (since if you're designing your own you might as well go straight there -- classic Apple move) which would need all the PCIe, DP etc plumbing they are currently getting from Intel.
Certainly doable, but there's a lot more boring spadework needed beyond the sexy CPU.
* This is why I always laughed when I saw articles comparing laptops by CPU clock speed rather than actual performance.
In short, thunderbolt. I suspect they went to the USB Type-C connector (on the iPad Pro) mainly for power delivery and while they got DisplayPort, they don’t have full peripheral support. USB 3.1g2 (putatively 10 GBPs) is the fastest supported; may be ok for an iPad but not really suitable for a non-archival external disk.
These limitations are perfectly reasonable for an iPad but not for a laptop.
FWIW nothing but a single TB 4 port (not even an audio jack) would work just fine for me, but I know some others feel differently for their use.
Thunderbolt is almost entirely Intel-only; IMO not having Thunderbolt on type-C ports certainly doesn’t make something not “laptop-class.” By that metric, the most powerful AMD laptops wouldn’t qualify either.
It's almost certain this is why Apple has taken so long to move their laptops (and desktops, eventually, probably) to ARM. The top-of-the-line iPhone has been benchmarking at or around MacBooks for the past 2-3 years.
I think backwards compatibility is a bigger stumbling block than support for peripherals. x86_64 emulation on ARM is still pretty bad AFAIK and there is a tremendous amount of Mac software that won't be ported on the first day, or ever in some cases.
I wonder if there are (legal) hurdles to Apple adding an additional x86_64 front end to their custom Mac chips to have hardware 'emulation' for backwards compatibility.
They could get around that by simply buying AMD who has an old-but-still valid second source license from intel plus of course the true 64-bit x86 architecture.
They could also just license it from Intel. AMD has some hot designers (some who cycled through Apple!) but overall has little to add to Apple (in my ignorant-of-the-true-state-of-Hines opinion. And I admire both companies).
Apple’s never been afraid to license something rather than do a perfectly legal legal clean room but-almost-perfect clone.
I suppose that’s possible but quite hard to believe. That license dates back at least to the 286, perhaps And more likely to the 8086 (I’ve long since forgotten) and dates from a time when multi-source parts were not just very common but required for military and most commercial design-ins. So common that when a part didn’t have a second source it was noticeable. The second source agreement had to be transferable else it would defeat its own purpose (if the second source went out of business nobody would buy your part).
Now of course I’ve never seen the intel/amd agreement so I’m just speculating as to what it says. But the weight of precedent/tradition makes a prohibition on transfer unlikely.
Microsoft has an x86 emulation, so it seems to be okay. It notably doesn't work with 64 bit software. From what I've been able to gather the issue is technical, but I'm very uncertain about it.
Worth remembering it was AMD who created x86_64. It was Intel who created x86. Granted, they’ve both added their own features on top of the basic x86_64 set, so it would be a legal hurdle.
They only have two options there as I see it. Either the emulator only runs on a single core per process, or they have an ARM with (maybe optionally?) stronger than required for ARM consistency guarantees.
>I think backwards compatibility is a bigger stumbling block than support for peripherals.
The recent Catalina update that caused a bunch of older programs to simply stop functioning strongly implies Apple doesn't care that much about being backwards-compatible any more.
But they never really have. iDevices seems shorter than laptop/desktop, but either way, they definitely have short support in terms if iOS hardware compatibility.
My theory is that the 64-bit only migration was done to weed out old apps and APIs that won't be ported to ARM and won't work in emulation. Killing 32-bit removed stuff like classic QuickTime and the whole Carbon API.
I don’t think backwards compatibility is an issue.
A device that initially only runs what Apple ships (web browser, Pages, Keynote, and Numbers) plus a few essential iOS apps (Facebook, WhatsApp, etc), priced competitively, is good enough to create a sizable market.
MS Office, FireFox, Chrome, and the like only are only nice to have at launch. It’ll be fine if it takes a few months for them to become available. They probably can do without Photoshop for years.
I tend to disagree. It might be possible to do something like this, but it'd certainly be hard, as the initial public perception will be "nothing works" - that's a pretty dangerous way of entering the feedback loop.
Apple isn't Microsoft, but their consistent failure attempting something like this may be a tale of caution.
I think Microsoft and Adobe are probably the easiest ones for them to get on board for launch (or 6 months after launch), since both of them have their core code ported to ARM already.
That has been very true historically (Intel/Cocoa shifts), but Apple and Adobe have been publicly shaking hands and smiling a lot about these new full Photoshop for iPad builds lately, so things look a bit better now.
Cautionary factor with those benchmarks: peak performance and sustained performance aren’t the same and Intel’s desktop and server chips have historically done much better in regards to sustained performance.
I’ve tried using an iPad Pro as a computing platform to run some of my code (mostly for fun but also it makes for a more interesting demo) and this is quite noticeable.
I think part of up this is simply because of Intel’s design approach, and also because Apple’s target is devices that can run quickly and then go to sleep to save power/heat.
Not to imply that Apple couldn’t design for that but it isn’t a mobile use case that they have been shooting for to date, and I suspect the current, publicly released chips would not be appropriate for a laptop much less an iMac.
Seems like apples and oranges to compare a passively cooled iPad to an actively cooled desktop/server. Does the iPad even have a heatsink or does it radiate through the case?
That’s my point: Apple’s parts are designed for a different design point so the benchmarks, while fun and interesting, don’t really compare like to like.
Apple’s ipod designs remind me in spirit of the design of the Alto: focused on the display before anything else.
Generally, the more difficult problem is to design the power-sipping, energy-efficient cpu that runs on a battery with passive cooling, than the relative power hog that plugs into the wall and has active cooling.
>The top-of-the-line iPhone has been benchmarking at or around MacBooks for the past 2-3 years
This just isn't true. I looked up some benchmarks. The iPhone X with the A11 Bionic got a Geekbench score of 918 for single core and 2368 for multi-core. To put that in perspective an old 15-inch MacBook Pro from 2013 with a Core i7-3840QM clocked in at 820 and 3199 respectively.
The counter to this argument is that why is Apple putting so many resources to making a keyboard case for the iPad Pro and adding trackpad support.
Is this some kind of test for when they move to ARM? Or do they want to do what they have done before and cannibalize the Mac platform for non professionals?
It could be that their customers are growing up with their platform.
Kind of like how the Honda Civic has gotten bigger with more features over the years, to where it surpasses the original Accord. I'll bet the Honda Fit from now will grow in the same way and they'll have to invent a new "budget honda" for the next generation of young people.
A reason cars keep getting larger is fuel-economy laws.
> Expanding a car's footprint — the wheelbase multiplied by the track width — gives it a lower fuel-economy target to meet under the CAFE standards negotiated by automakers and regulators.
During diesel gate I did a lot of research, none of which I still have sadly. Diesel emissions regulations were generally slightly stricter in the U.S. I found that pretty surprising at the time.
The latter, of course. It's not even subtle, they've tried to tell us that you can do (almost) everything on a tablet ever since they announced the original iPad Pro. Then MS proved their point with the Surface, except they also proved people like to work with real keyboards. So now Apple are doing keyboards.
That's why I'm skeptical that we'll ever get an "Arm MBP". Apple would rather do away with laptops, they see them as annoying and expensive legacy that just happens to be unreplaceable at the moment. There is no point investing into a massive and bloody transition of a segment you are trying to divest from.
It's worth noting that the original iPad also had a keyboard available - it was just a keyboard stand, not a cover. Not the same as the portability that a keyboard cover offers, but it was what could be feasibly offered with the technology at the time.
Uhm, I'm pretty sure Asus was shipping Surface-like models already, back then. They were not great (because Asus is not Apple, with all due respect), but sold out the initial runs.
Also, part of the UI rethink has to happen in the OS, which is why Apple eventually spun out a dedicated tablet OS. They are coming around.
If they did away with laptops how could they expect developers to respect their license to only compile Apple apps on their OS? They can’t expect super users to work from tablets. I’d be curious if they would put this constraint on their own developers given their strict deadlines and work hours.
> Apple would have to have all the support chipset as well.
Hasn't Apple been pretty obviously moving in that direction? Their T2 chip does a lot. Given how Intel doesn't let third-parties make alternatives to their own southbridge chipsets any more (a change that screwed Apple's product strategy at the time), there's not much more that Apple could move into the T2 until they're ready to abandon Intel CPUs, too.
Intel used to only make the CPU in the PC platform. It joined the chipset game sometime in the late 80s or early 90s and eventually pushed everyone like VIA, SiS, OPTi out.
Just about all peripheral communications standards for consumers are open standards, like PCIe, USB, SPI, Ethernet, SATA, SAS, and even Thunderbolt now. The only problem I could think of would be the Intel-owned HDMI but it's nothing DisplayPort + a simple dongle can't sidestep.
I know Apple couldn't depend on Intel for it's basic GMA acceleration anymore but it could simply use what's in the iPhone for basic display acceleration.
Alright, but Intel isn’t exactly RIM, they can adapt. They’ve been around for quite a while now! I obviously applaud the competition, both from AMD and ARM
Can they adapt in time? Being "around for a while" means nothing. There are thousands of big-name businesses that fail all the time after being in business for decades, or even centuries. As they say, past performance is not an indicator of future success...
I couldn’t find any numbers for the server market, but Apple alone sells more products based on their chip design than all of the personal computers sold worldwide.
Intel has already lost the mobile market, threw the towel in on the cellular chip market and sold the division to Apple, lost the console market to AMD, and the worlds largest cloud provider AWS has started selling access to both AMD and ARM servers at a much cheaper cost/cpu rate.
The education market is rapidly moving to ARM based Chromebooks.
> "As investment and development dollars continue flowing into the dominant mobile platforms — Android and iOS — it’s logical to expect that every useful desktop application that hasn’t yet been adapted to them already is on its way there."
I'm unsure whether some classes of desktop applications can ever be as useful on mobile platforms as they are on the desktop. I'm thinking of applications that legitimately need a lot of screen estate to stay useful like digital audio workstations or IDEs with extensive debugging support.
I contend that useful desktop applications are sometimes useful precisely because they run on a desktop.
Mobile first applications make software difficult to use, compromising features to the limited nature of mobile devices.
It is a worrying trend driven not by practical but appearance focused design not only corrupting desktops but the web too.
So many good old software or solutions go down the drain being ported to mobile platform and becoming increasingly difficult to use or/and pure dumb.
Mobile platforms are auxiliary from productivity point of view, never can be the main thing. Have its good place where it shines but fails terribly elsewhere. Putting into the centre brings degradation.
Working on a handheld device with fingers requires different approach than keyboard and mouse put on a desk together with the device, the trouble is with the OS and software not with the technical specification. If those are made for one, effective for one, will be crippled for the other. Also try using the same software on both 5" and 32" and with either finger only or keyboard and mouse only, efficiently. Good luck with that!
If powerful processor and plenty of RAM would make a laptop then your Playstation was a laptop too! :)
I'm honestly somewhat surprised in all these discussions that one word hasn't come up a lot more frequently, more so as the years go by: patents. Patents under the current regime last 20 years. AMD64 was a 1999 announcement and spec was out in 2000 IIRC, 1st implementation (Opteron?) was like 2003, Conroe was 2006. And chip designs are done years before mass fabbing too.
All of which means that, starting this year and definitely in the next few years all possible patents on the core x86-64 standard will expire, with each additional year bringing a few extra extensions. As far as what Apple requires to run historic macOS code, they clearly have not built a dependence on every cutting edge new instruction. They officially supported 2010 Mac Pros (which were on the Westmere chips) until last year, and 10.15 can still be made to run on them.
Ever since Apple giving up on Intel chips has been discussed one general assumption/objection that I have always seen essentially assumed is that it also means abandoning x86 too, and in turn an enormous amount of macOS software, compatibility, etc. But need that actually be the case? x86-64 going patent free for all the essential parts opens up a lot of options for a lot of players. Maybe I've missed a lot of discussion (and if so I'd love to be directed to it) but so far I really haven't seen it considered much. 20 years is a long time in tech, but it's not forever. Without IP holding them back, need Apple ever give it up? They can focus on ARM, but a high performance hardware/software translation layer would certainly change the math around a transition wouldn't it?
I think the big problem here is that code which really needs to be run on native x86-64 hardware rather than through emulation/dynamic translation is likely to also be code that uses newer instruction set extensions that Apple would have to license.
And there are similar articles in 2019, 2017, 2016, all the way to 2011 [1].
One of the thing about these rumours is that they are always 6 months or so before another new Mac product launches or refresh. It could also have been coincidence since Mac used to update once a year, and any rumours would always fit into that time frame.
But I cant help and wonder if this is just a tactics from Apple on pricing. Apple doesn't get any marketing subsidies from the Intel stickers since Apple dont use any of those. Surely Apple would still want an equivalent incentives if not more.
There were similar persistent rumors about Apple having a build of OS X running on x86 back in The Day. I dismissed them as wishful thinking by the rumorer. One day Apple announced x86 Macs and I was simply shocked.
As far as I am aware, Apple had been running x86 OSX before even Steve knew about it. So the 5 years double life secret agent was merely a marketing pitch. The whole story was written on cake.co
But what was clear though was Steve wanted a notebook, and Intel Centrino was the perfect fit. And the roadmap from IBM was a dead end. And it was very obvious, ( unless you belong to those group that does not believe in Notebook market) that switching to Intel was the only choice.
But this time there is nothing ARM / Apple CPU can do that Intel cant. The only real advantage Apple get is cost reduction. Intel isn't like IBM where it has no low power roadmap, and Intel's IPC aren't far behind either.
The public always gets constantly bombarded with "Apple rumored to do _X_ in _Y_ months" news articles. I always wondered how accurate those predictions turn out to be since I don't think anyone ever does a retrospective on the accuracies of those fodder of news articles.
Kuo has been dead accurate in terms of iPhone predication. Simply because it may likely be impossible to have an Smartphone shipping 40M unit within a few months and not to have any Supply Chain leaks. It is, By SKU/Models the best selling Smartphone on the planet.
Less so on the Mac because of the much smaller visibility. But generally speaking he does tends to get it right before anyone else as we are closer ( months before launch ). Those who claims to be accurate are often weeks before launch. There are so fundamental differences.
I was at Sun around 2002 or so, when the writing was on the wall about SPARC perhaps not being the best long-term plan and various x86 projects starting.
I hope Apple learns from Sun's mistakes.
Also, somewhat related: does anyone remember Transmeta? They were about a decade too early but their ideas on low-power, low-heat x86-compatible mobile-friendly processors were pretty cool. https://en.wikipedia.org/wiki/Transmeta
Apple has built an ecosystem of automatic app re-compiling for new architecture. Every AppStore app that is built using modern (last 5 years) tools and xcode, in theory, should be transparently re-compilable to a different uarch. Apple currently does this with watchos apps.
So, yes, they learned. I suspect they will ship an x86 emulator as they did with Rosetta, additionally.
for between arm variants that is true, but bitcode is still tied to the target architcure [1], so transparent re-compiling x64 bitcode into arm64 is unlikely unless apple has done some changes to how bitcode works that im unaware of
Sun never had the volume Apple does. SPARC was far from competitive with x86 in its later days, unlike Apple's A-series chips.
Transmeta? I was there from ~2001 until we closed the doors. What some people still don't understand was that Transmeta's failure was a business failure, not a technical one. When Crusoe launched it had greater power efficiency than Intel's chips. Intel has _officially_ credited Transmeta with kickstarting Intel's focus on power. Execution and business failure cost Transmeta to slip more than a year at which point opportunity and customer goodwill had sailed. Someone really should write a book about all the drama.
No I'm not a writer and I don't have nearly the insights needed. I'd read it though.
I have been around compiler internal formats and "bytecode" representations since the mid 80es. WASM is simply brilliant for what is designed for. I'm particularly in love with the structured control flow (key for enabling 1-pass translation). I used a block structure IR a compiler IR in the mid-90es. (EDIT: am I being trolled?)
I think wasm will be the portable bytecode we have all been promised. It will literally run our flying cars.
It also melts away the need for an MMU and because of that, the operating system. Requiring an OS, kernel/user code is no longer referentialy transparent, but with wasm, you can basically have an infinite number of hypervisors.
I'm carefully optimistic that WASM could point a path out of our legacy. It has a lot of potential and opens up new possibilities, so please use it and contribute improvements :)
On the one hand I like this idea because I'm tired of Intel's lousy security and lousy energy budget. On the other hand I dread it because Apple will not fully document the ISA of their new CPU (just like with their current mobile lineup) which means it will become impossible to develop one's own programs for the Mac, write code in whatever language you wish, or distribute programs for the Mac outside the Apple-controlled walled garden. You'll use Swift and Xcode and you'll distribute your programs via the App Store with Apple's approval, and you'll like it. Or you won't develop for the Mac.
I write code in c++ (using Emacs), compile it with the latest (non-Apple) llvm, and link it with some UI code I developed with Xcode. I can even compile from within Emacs by calling xcodebuild (though these days I just have cmake do that).
Or compile it all in Xcode. Not terrible, I just happen not to like guis.
I think it's incorrect assumption. If you want to develop a compiler for this new ISA, you'll develop a compiler into Clang's IL (intermediate language, that's probably incorrect name, I'm not a specialist in compilers) and then Apple's Clang will do the rest. Or may be even Apple will develop that part of Clang and make it open source then this is your documentation effectively.
This is an important lesson. I am personally not a fan of the Windows programming model* and I despair the number of security holes over the years, but I am quite aware that a large part of it stems from Microsoft's commitment to extreme backwards compatibility (which I also recognize has sometimes taken heroic measures).
I'm actually surprised how long Apple takes to obsolete APIs (carbon lingered forever) and how far back they are willing to support old hardware. They project an insouciance towards old APIs but tend to give a lot of advanced warning (e.g. the obsolescence of 32-bit applications was announced at least five years ago). They seem to be far less conservative towards UI, and prefer to rewrite rather than update which leads to a bunch of new bugs. That might be what gives people the impression that they junk APIs quickly.
* that's a matter of personal taste, not meant to start a flame session.
LLVM will almost certainly get a back-end for it; Apple uses the latter extensively already. And virtually all new, native language projects already target LLVM. So I don't see this being a problem at all.
179 comments
[ 3.3 ms ] story [ 235 ms ] thread> starting sometime around 2020
That prediction hasn't proven wrong yet, but it's looking increasingly unlikely. If the Mac were a bigger part of their revenues, they'd probably be further along in the transition though.
AMD already has ARM server experience with the https://www.amd.com/en/amd-opteron-a1100
Apple has done this twice before(68K and PPC), and currently runs a split CPU architecture ecosystem - granted there are hard product delineations between them today, but there aren’t any significant technical reasons why Apple couldn’t effectively support both ARM and Intel Macs - and do so for an indefinite period of time.
The real issue is MBPs.
* Apple tried to drop it once before (but the 12’ MacBook didn’t do well enough to usurp the MBA)
* The latest iPad advertisement talking about “your next computer” and the keyboard + trackpad attachment
Aberration May be a bit strong. Stopgap living beyond its intended life may be more appropriate?
Meanwhile, it's 2020 and and x86 instruction sets upgrades are infrequent compared to ARM. And x86 CPUs still are required to support 16-bit devices from 35 years ago.
I heard somewhere that this year Intel was going to begin to phase out support for BIOS, which would allow Intel to eliminate CPUs booting up in "real mode".
I think as long as plain PCI is something supported, some sort of 16-bit support has to be in the firmware because of option ROMs. Though I'm not sure UEFI couldn't service those with some sort of emulation layer (may as well, UEFI's already complex enough).
Also, the x86 instruction set gets upgraded with practically every single generation of Intel and AMD processor.
RISCV, on the other hand...
Jokes aside the real reason why it's extremely unlikely is that they put a lot of money into ARM and they simply have no reason to switch to it. For this to happen ARM would need to do something like massively increase the price of their IP licenses, or simila. Which won't happen.
For all intents and purposes, RISC-V being open just puts it on the same footing for Apple as ARM is for them.
Even more baffling, is that the same extension that adds integer multiplication, also requires integer division, telling me that the spec authors think that multiplication and division are of the same circuit complexity, and used with the same frequency. And for one example for how goofy of an idea that is, ARM has never included integer division in its core ISA.
Then there's the whole JALR mess, which I don't know how to describe it other than "tech debt". Basically, they tried to simplify different kinds of jumps and returns into a single extension, by allowing any register to be used for the source and destination addresses. But for branch prediction reasons, and prefetching, you really do want to have a single link register, so the spec says "please don't use anything other than x1 as the link register, or you might not get proper performance".
There's a lot more that I can go into.
Those use cases work just fine with the shifts and adds trick you can do for multiply by constant. Honestly I was always baffled that ARMv6-M required a multiplier. Seemed to be the closest thing to an albatross over it's head, so much so that there were those M0's with an iterative, 32 cycle latency, bit serial multiplier.
> Even more baffling, is that the same extension that adds integer multiplication, also requires integer division, telling me that the spec authors think that multiplication and division are of the same circuit complexity, and used with the same frequency. And for one example for how goofy of an idea that is, ARM has never included integer division in its core ISA.
ARMv7-M (the closest ISA to Rv32-EM) requires integer divide.
> Then there's the whole JALR mess, which I don't know how to describe it other than "tech debt". Basically, they tried to simplify different kinds of jumps and returns into a single extension, by allowing any register to be used for the return address. But for branch prediction reasons, you really do want to have a single link register, so the spec says "please don't use anything other than x1 as the link register, or you might not get proper performance".
I don't really see this as a problem. For instance it neatly encodes unconditional jump without link as a jump with link to x0. Reminds me of some of the cute ways to encodes jumps from SH without being quite as ascetic.
> There's a lot more that I can go into.
Please do. Like totally unironically. I obviously have a pretty high opinion of RISC-V, but I appreciate someone who helps keep my biases in check.
I was under the impression that cores with only a hardware multiplier could emulate the division instruction.
From the ISA specification[1]: "RV32I can emulate almost any other ISA extension".
[1]: https://riscv.org/specifications/isa-spec-pdf/ (Chapter 2, RV32I Base Integer Instruction Set,)
What's wrong with supporting a slow path? The alternative is to say x1 is always used, in which case you don't get the flexible, but more costly, alternative register variant, no?
I think those transform to an integer multiplication…like never? They're almost always an offset to a base pointer that's incremented as you go through the loop…
And? Base RISC-V is meant to be as simple as possible; if you're designing an ultra-low power microcontroller you probably don't want a hardware multiplier, and you shouldn't be forced to have one. The "G" general purpose set of extensions is what you need for an application processor.
Something like RV64GC would be what most compiler writers would be targetting.
> telling me that the spec authors think that multiplication and division are of the same circuit complexity
Given the profiles of the spec authors I highly doubt this is the case; the number of modern cores which support hardware multiplication but not division is very small.
> Anybody that's written a compiler or even stared at assembly would tell you how prevalent integer multiplication is, for any sort of loop or pointer addressing.
For a loop you'll probably try to avoid as much multiplication as possible by transforming the induction variable to make it amenable to strength reduction.
or the arguments against an operating system in C instead of assembler years before that.
The licensing terms are what make risc-v interesting and the technical arguments won't stand the test of time.
A64 is part of ARMv8 which was announced in October 2011 and was a brand new instruction set. It is not compatible with legacy 32 bit ARM applications and doesn't carry the relevant technical debt.
RISC-V was announced in 2010. It may have many admirable qualities but claiming that it has the advantage of a newer architecture is not correct in this context.
Incidentally, I think one of the remarkable features of ARM's recent commercial success - generally completely unremarked on - is how they have, relatively seamlessly, switched users from legacy 32 bit to an new 64 instruction set.
Nothing prevents them slapping ARM frontend onto Zen
The switch from 68k to PowerPC was because PowerPC was an extremely powerful up-and-coming architecture at the time. A PowerMac 7100 (one of the earliest models) blew a 68040 Mac out of the water.
So when IBM came to them asking "hey how about we scale down POWER to a desktop chip for you?" Apple also brought in Motorola so that they could dual-source their chips and not be dependent on one company, and PowerPC was born. Rather than being an up-and-coming competitor, PowerPC probably wouldn't exist without Apple's involvement (they would probably still have pursued a scaled-down POWER, but it wouldn't be PowerPC)
Thankfully I’m not clinging to any older unsupported apps so I realize it’s easy for me to be pro ARM Mac - which is why I don’t expect Apple to go ARM only any time soon but offer a choice for quite a while while the market settles out.
And who knows, Intel could turn it around. They haven’t managed for the last 7 years or so, but I suppose it could still eventually happen.
Two points to think about on this issue:
1) When Apple moved away from PowerPC, they did so entirely.
2) Apple historically* wanted to keep its hardware offerings simple and easy to understand, and supporting multiple architectures could muddy their offerings.
* When Jobs returned to Apple, he killed the confusing lineups in favor of one option each of desktop or mobile, for pros and home users. This has changed a bit lately, but I can imagine ARM and Intel options of Macbook vs Macbook Air vs Macbook Pro being a nonstarter.
Anyway, I agree, an ARM Macbook Air would be awesome, assuming the software followed suit.
But if, eg, MacBook Air turns into MacBook ARM but MacBook Pro remains Intel - this would be a very difficult schism. Many publishers might look at it as being pro customers staying on Intel and cost-sensitive customers on ARM, which could damage adoption.
The risk is having no carrot and no stick - not entirely dissimilar to Itanium's problem.
Not to mention that they are shipping an iPad version already.
Even Adobe's transition from PPC to Intel took 15 months after Intel Macs started shipping and 22 months after the x86 Mac dev kits were publicly announced (though I wouldn't be surprised if Adobe had a heads-up if not actual dev kits even before Apple publicly announced their Intel transition).
And let's not forget all the fuss Adobe made when the rest of the world was ready for Flash to die. This company has a history of being very defensive about their technical debt.
…which has historically been fairly terrible at being either.
I expect the transition to be done before the end of 2022, with intel support being dropped from the latest OS two years later, and no more macOS updates for intel-based macs two years after that.
Not a thing what I would normally do but my rendering desktop was out of commission for a few days while waiting for parts to arrive.
that was the point that apple realized intel had become incapable of leading the industry any longer and started looking beyond intel.
I would love an AMD MBP. Intel's chips have rapidly diminishing value for pretty much all use cases and AMD is firing on all cylinders with Dr Lisa Su.
Then they will slowly deprecate MacOS, but only after they made sure that development of software can be done one the modified version of iOS.
Through that's just a wild guess.
It just doesn't make sense to adapt iPadOS even more to a MacBook Air computer if they're not going to include a touchscreen. With them holding out as long as they have on touchscreens, I can't imagine them reversing course.
Apple had been letting Macs and Mac OS languish for a few years but has really stepped up their game over the last couple of years. I think they will keep them separate for a long time while brings things together under the hood.
Apple certainly has Mac OS ported for Arm and they also certainly have their own apps cross-compiled for Arm Mac OS. Once the OS and libraries are ported, the apps are relatively easy to adapt to the new system.
Certainly doable, but there's a lot more boring spadework needed beyond the sexy CPU.
* This is why I always laughed when I saw articles comparing laptops by CPU clock speed rather than actual performance.
What would make it laptop-class, other than by adding more USB-C ports?
These limitations are perfectly reasonable for an iPad but not for a laptop.
FWIW nothing but a single TB 4 port (not even an audio jack) would work just fine for me, but I know some others feel differently for their use.
Considering that USB4 will be Thunderbolt 3 compatible, I'd guess that we'll start seeing more Thunderbolt ports soon.
They could also just license it from Intel. AMD has some hot designers (some who cycled through Apple!) but overall has little to add to Apple (in my ignorant-of-the-true-state-of-Hines opinion. And I admire both companies).
Apple’s never been afraid to license something rather than do a perfectly legal legal clean room but-almost-perfect clone.
I doubt they’d bother.
Now of course I’ve never seen the intel/amd agreement so I’m just speculating as to what it says. But the weight of precedent/tradition makes a prohibition on transfer unlikely.
Both options kinda suck.
The recent Catalina update that caused a bunch of older programs to simply stop functioning strongly implies Apple doesn't care that much about being backwards-compatible any more.
As for hardware lifetime...I’m still using a 2014 iPad, 2015 iPhone and only stopped using my 2015 MacBook because it got caught in the rain.
A device that initially only runs what Apple ships (web browser, Pages, Keynote, and Numbers) plus a few essential iOS apps (Facebook, WhatsApp, etc), priced competitively, is good enough to create a sizable market.
MS Office, FireFox, Chrome, and the like only are only nice to have at launch. It’ll be fine if it takes a few months for them to become available. They probably can do without Photoshop for years.
Apple isn't Microsoft, but their consistent failure attempting something like this may be a tale of caution.
I’ve tried using an iPad Pro as a computing platform to run some of my code (mostly for fun but also it makes for a more interesting demo) and this is quite noticeable.
I think part of up this is simply because of Intel’s design approach, and also because Apple’s target is devices that can run quickly and then go to sleep to save power/heat.
Not to imply that Apple couldn’t design for that but it isn’t a mobile use case that they have been shooting for to date, and I suspect the current, publicly released chips would not be appropriate for a laptop much less an iMac.
Apple’s ipod designs remind me in spirit of the design of the Alto: focused on the display before anything else.
This just isn't true. I looked up some benchmarks. The iPhone X with the A11 Bionic got a Geekbench score of 918 for single core and 2368 for multi-core. To put that in perspective an old 15-inch MacBook Pro from 2013 with a Core i7-3840QM clocked in at 820 and 3199 respectively.
https://browser.geekbench.com/ios_devices/52
https://browser.geekbench.com/v5/cpu/1997421
And they've been shipping PCI-e on their chip for T2. I'm pretty sure the iPad displays are Embedded Display Port, but don't have a source for that.
0: https://emerythacks.blogspot.com/2013/04/connecting-ipad-ret...
Is this some kind of test for when they move to ARM? Or do they want to do what they have done before and cannibalize the Mac platform for non professionals?
Kind of like how the Honda Civic has gotten bigger with more features over the years, to where it surpasses the original Accord. I'll bet the Honda Fit from now will grow in the same way and they'll have to invent a new "budget honda" for the next generation of young people.
> Expanding a car's footprint — the wheelbase multiplied by the track width — gives it a lower fuel-economy target to meet under the CAFE standards negotiated by automakers and regulators.
https://www.autonews.com/article/20160814/OEM11/308159946/is...
https://www.theonion.com/a-statement-followed-by-a-question-...
That's why I'm skeptical that we'll ever get an "Arm MBP". Apple would rather do away with laptops, they see them as annoying and expensive legacy that just happens to be unreplaceable at the moment. There is no point investing into a massive and bloody transition of a segment you are trying to divest from.
Also, part of the UI rethink has to happen in the OS, which is why Apple eventually spun out a dedicated tablet OS. They are coming around.
It was not technological limitations preventing Apple from making one themselves.
Hasn't Apple been pretty obviously moving in that direction? Their T2 chip does a lot. Given how Intel doesn't let third-parties make alternatives to their own southbridge chipsets any more (a change that screwed Apple's product strategy at the time), there's not much more that Apple could move into the T2 until they're ready to abandon Intel CPUs, too.
Just about all peripheral communications standards for consumers are open standards, like PCIe, USB, SPI, Ethernet, SATA, SAS, and even Thunderbolt now. The only problem I could think of would be the Intel-owned HDMI but it's nothing DisplayPort + a simple dongle can't sidestep.
I know Apple couldn't depend on Intel for it's basic GMA acceleration anymore but it could simply use what's in the iPhone for basic display acceleration.
Intel has already lost the mobile market, threw the towel in on the cellular chip market and sold the division to Apple, lost the console market to AMD, and the worlds largest cloud provider AWS has started selling access to both AMD and ARM servers at a much cheaper cost/cpu rate.
The education market is rapidly moving to ARM based Chromebooks.
I'm unsure whether some classes of desktop applications can ever be as useful on mobile platforms as they are on the desktop. I'm thinking of applications that legitimately need a lot of screen estate to stay useful like digital audio workstations or IDEs with extensive debugging support.
I contend that useful desktop applications are sometimes useful precisely because they run on a desktop.
Imagine a 15" iPad Ultra Pro with comparable hardware, running iOS, with wireless keyboard and mouse / touchpad. Could it be a real workstation?
If powerful processor and plenty of RAM would make a laptop then your Playstation was a laptop too! :)
All of which means that, starting this year and definitely in the next few years all possible patents on the core x86-64 standard will expire, with each additional year bringing a few extra extensions. As far as what Apple requires to run historic macOS code, they clearly have not built a dependence on every cutting edge new instruction. They officially supported 2010 Mac Pros (which were on the Westmere chips) until last year, and 10.15 can still be made to run on them.
Ever since Apple giving up on Intel chips has been discussed one general assumption/objection that I have always seen essentially assumed is that it also means abandoning x86 too, and in turn an enormous amount of macOS software, compatibility, etc. But need that actually be the case? x86-64 going patent free for all the essential parts opens up a lot of options for a lot of players. Maybe I've missed a lot of discussion (and if so I'd love to be directed to it) but so far I really haven't seen it considered much. 20 years is a long time in tech, but it's not forever. Without IP holding them back, need Apple ever give it up? They can focus on ARM, but a high performance hardware/software translation layer would certainly change the math around a transition wouldn't it?
One of the thing about these rumours is that they are always 6 months or so before another new Mac product launches or refresh. It could also have been coincidence since Mac used to update once a year, and any rumours would always fit into that time frame.
But I cant help and wonder if this is just a tactics from Apple on pricing. Apple doesn't get any marketing subsidies from the Intel stickers since Apple dont use any of those. Surely Apple would still want an equivalent incentives if not more.
[1] https://arstechnica.com/gadgets/2011/05/apple-could-adopt-ar...
But what was clear though was Steve wanted a notebook, and Intel Centrino was the perfect fit. And the roadmap from IBM was a dead end. And it was very obvious, ( unless you belong to those group that does not believe in Notebook market) that switching to Intel was the only choice.
But this time there is nothing ARM / Apple CPU can do that Intel cant. The only real advantage Apple get is cost reduction. Intel isn't like IBM where it has no low power roadmap, and Intel's IPC aren't far behind either.
Less so on the Mac because of the much smaller visibility. But generally speaking he does tends to get it right before anyone else as we are closer ( months before launch ). Those who claims to be accurate are often weeks before launch. There are so fundamental differences.
I hope Apple learns from Sun's mistakes.
Also, somewhat related: does anyone remember Transmeta? They were about a decade too early but their ideas on low-power, low-heat x86-compatible mobile-friendly processors were pretty cool. https://en.wikipedia.org/wiki/Transmeta
So, yes, they learned. I suspect they will ship an x86 emulator as they did with Rosetta, additionally.
[1] https://www.infoq.com/articles/ios-9-bitcode/
Sun never had the volume Apple does. SPARC was far from competitive with x86 in its later days, unlike Apple's A-series chips.
Transmeta? I was there from ~2001 until we closed the doors. What some people still don't understand was that Transmeta's failure was a business failure, not a technical one. When Crusoe launched it had greater power efficiency than Intel's chips. Intel has _officially_ credited Transmeta with kickstarting Intel's focus on power. Execution and business failure cost Transmeta to slip more than a year at which point opportunity and customer goodwill had sailed. Someone really should write a book about all the drama.
What do you think about wasm?
I have been around compiler internal formats and "bytecode" representations since the mid 80es. WASM is simply brilliant for what is designed for. I'm particularly in love with the structured control flow (key for enabling 1-pass translation). I used a block structure IR a compiler IR in the mid-90es. (EDIT: am I being trolled?)
I think wasm will be the portable bytecode we have all been promised. It will literally run our flying cars.
It also melts away the need for an MMU and because of that, the operating system. Requiring an OS, kernel/user code is no longer referentialy transparent, but with wasm, you can basically have an infinite number of hypervisors.
Or compile it all in Xcode. Not terrible, I just happen not to like guis.
I'm actually surprised how long Apple takes to obsolete APIs (carbon lingered forever) and how far back they are willing to support old hardware. They project an insouciance towards old APIs but tend to give a lot of advanced warning (e.g. the obsolescence of 32-bit applications was announced at least five years ago). They seem to be far less conservative towards UI, and prefer to rewrite rather than update which leads to a bunch of new bugs. That might be what gives people the impression that they junk APIs quickly.
* that's a matter of personal taste, not meant to start a flame session.