I seriously doubt Apple will allow others to use their secret sauce. Still, more people using ARM software will certainly result in better tested libraries and tools. Intel got where it is now by having a machine on pretty much every developer's desk (it can be said that SPARC and MIPS got where they are now by having an x86 on every developer's desk too). When a lot of developers have ARM boxes on their desks, a lot of software will be written for ARM first and ported to x86 as an afterthought - or, more accurately as Apple's tooling goes, built for ARM and x86 but only tested on ARM.
You could rip an M1 chip out of a Mac, but then you have the problem that there are no publicly available device drivers for many of the peripherals integrated on to the chip, such as the proprietary Apple GPU cores, neural engine and probably also things like the thunderbolt and other interface components. Also how does the kernel manage things like the BIGLittle cpu architecture, power management systems, etc.
What could be very interesting though is emulating a Pi on an M1 Mac in virtualisation.
I think what OP is suggesting isn't so much that Pis will use M1 chips, more that right now typically many applications are unavailable as prebuikt binaries for arm64, and maybe having more arm processors in the wild will make that situation change.
I just switched to the starship shell prompt on my mac, for example, and I tried to install it on my Pi as well, but there's no prebuilt binary for Pi, and after an hour or so I gave up trying to build it myself. :P
This especially won't happen because from Apple's perspective, that's way too similar to a Mac mini. The Mac mini just has an aluminum enclosure, heatsink, and fan. Remove those three things, downclock the CPU (if possible), and you've got a close equivalent.
It would be awesome, but one of the great things about Raspberry Pis is how inexpensive they are, and I think the M1 is probably pretty expensive—even for Apple.
It matters because their uses is different, which forces different design requirements, memory constraints, different multitasking and network environments and assumptions...
Also, for a large number of these devices, they run Java-ish code on a Java-ish VM.
Very few, however native desktop applications are becoming a rarity these days anyway. A small number of professional apps and games, but game engines are already targeting ARM due to phones.
That made me think of an interesting point. I wonder how much of the M1's performance comes from just being able to press the reset button on backwards compatibility? In other words, if I take a latest generation AMD processor and compile every binary for it with all of the processor specific optimisations enabled how much faster would it be.
Not any time soon. Apple Silicon implements additional instructions not found on other boards, making software compiled for it potentially (read: probably) incompatible. There's also the presence of the security chips which Apple will likely assume to be present as it's not optional on ARM boards, so you'd need to patch checks and calls to that out.
Even if it does work, there'd be little use in it. Hackintoshes are popular because they offer performance beyond what you can buy for a reasonable price as a consumer. Alternative ARM devices are nowhere near as fast as M1, so that use case disappears completely.
There's also the bootloader issue. On x86 and x64 the boot process has been standardized into either BIOS or UEFI mode. On ARM there are standards comparable to UEFI, but most chip vendors have their own custom bootloader code to boot an OS. Most chipsets are compatible with Android or Linux but there's only one manufacturer who develops bootloaders for the macOS platform.
It's possible to get macOS arm64 working on Arm hardware (except Rosetta on Arm cores that don't implement TSO/SC, or you're stuck with a single core). However, Arm macOS assumes an Armv8.3-A architecture baseline. Patching at runtime from Armv8.3-A to v8.2-A is quite feasible, to 8.0-A like an RPi4 is another matter.
Yes, but Apple has added additional instructions to it. Any app that relies on those Apple-specific additional instructions would crash running on different chips.
Can you provide a source? Everywhere I've looked just shows MRS and MSR instructions, which are standard ARM instructions with platform specific operands/results. It can only be a custom instruction if the disassembly shows it's in the reserved instruction opcode space.
I think that other laptop and desktop manufactures will bring their own ARM-bases offers in a 2-3 years. Intel is not yet doomed, but this will be a harsh blow for them.
I doubt that. CPU design and manufacture is a huge investment. I don't think laptop/destop manufacturers are going to put their money in it. And without a performant ARM CPU supply (Apply doesn't show any sign of releasing M1 for general use), there's just no ARM-based offers.
Hopefully, it'd be nice to have some measures to ensure extremely cheap new computers (thinking of the Pi 400) would provide everything a child might need to do their school work without having to depend on bottom of the barrel 2GB ram laptop being sold at way more than they're worth
It already does since public benchmarks released yesterday. Not only Intel laptops, but M1 with 7-8W power drain in single-threaded performance beats or just trails in some benchmarks against a desktop class $799 Ryzen 9 5950x at +49W power drain.
Can they make an Air competitor? As far as I understand, not today.
I don't expect it to make a measurable difference. Android and iOS have already pushed ARM support and optimizations in programming languages and key libraries.
For macOS, the support revolves around Xcode. Cross-compilation support is Apple-specific and won't benefit Linux. CPU architecture is abstracted away in macOS as much as possible, so average developers won't think much about ARM support.
Where Apple wants developers to tune for M1 specifically, is their proprietary frameworks for ML acceleration and Metal, which don't benefit anyone but Apple.
At best there may be some halo effect from proving that ARM can be as fast as "real" desktop CPUs, and it's not just the low-end slow Qualcomm chips. That might legitimize running ARM on servers, but Pi is neither high-end desktop nor a server platform.
One could expect that docker on macOS with M1 will be able to run aarch64 linux container images and therefore make it more convenient for developers to better maintain open source libraries for this platform (without suffering from long build time on an under-powered external ARM box, or the complexity to setup a cross-compilation toolchain or the slowness of a qemu layer).
Linux will not run on the M1 until 1a) Apple decides to allow it or 1b) someone finds a boot chain exploit, and 2a) Apple releases full chip documentetion or a Linux port outright or 2b) People spend years reverse engineering it all until it works well.
I don't see 2a happening, and let's hope for 1a and time.
It's not exactly baseless since Apple actively opposes open computing. You can't even run an interpreter on iOS without Apple hammer coming down. They are slowly but surely moving towards not being apple to run anything not Apple on OSX as well. So I don't think it's baseless to suggest that Apple will try to actively lock this down.
> It's not exactly baseless since Apple actively opposes open computing.
> They are slowly but surely moving towards not being apple to run anything not Apple on OSX as well.
I would argue that both of these statements are completely baseless, and the second is actually actively argued against by Apple.
I'll be the first to say that their handling of iOS things is horrible, and I would buy iPhones and iPads if they were a more open platform, but the world is more complicated than "Apple is evil" and their handling of iOS has no bearing on the Mac.
I don't really care what they say themselves. They quite obviously continue to move OSX in that direction. First they made opening unsigned programs a little bit harder. Then they made it much harder. Now they don't allow any unsigned apps to run at all unless you opt-out at OSX install time. I really don't understand how you can believe this is not clear. Especially considering the iOS situation.
I believe it's not clear because Apple is set to gain nothing if they would move against "open computing", and only lose. iOS has not been an open computing platform since the start, and Apple appears to have trouble changing their backwards attitude there. There's no attitude to change on the Mac. Everything they've done on Mac nudges to strict defaults, but does not limit anyone (at best it improves security, at worst it annoys, but it does not fundamentally limit anyone). You can fully disable Gatekeeper with one Terminal command if those defaults annoy you.
In my view you can only believe Apple will lock down the Mac if you somehow view them as an irrational ideological opponent, not simply a company that wants to make money by selling computers. Since you say you don't care what Apple themselves say towards this, I can't escape the impression that you might actually already view them in this way. If so, there's not much we can talk about.
I don't know why they want to lock it down. I don't understand why they lock down iOS either. I also don't know why they are moving further on locking down OSX over time. I'm only observing what they are doing and extrapolate. I don't care what they are saying because it's worth nothing. I rather watch their actions.
I really would love nothing more then buy the new Apple Arm Macbook Pro but I can't risk investing in this ecosystem when, to me, it's quite obvious where Apple stands on this.
If you don't know why they want to lock it down, if Apple says they don't want to lock it down, and Apple Silicon Macs show no further evidence of things being locked down (they're just different), then why do you still think it's so evident they will lock it down? I honestly get the impression you're caught up in some narrative that has very little substantiation, just a fear that macOS will become iOS.
> I rather watch their actions.
And which actions are those? Gatekeeper and the Apple T2 are not enough to make the Mac not an "open computing platform", let alone something close to iOS. I'd argue they're not even on the way there, just like Windows SmartScreen isn't on the way there. And note that the T2 is even gone from Apple Silicon Macs.
Apple deserves all the added scrutiny in this area because of their attitude on iOS [1]. But there's absolutely no reason to believe that Apple's direction towards locking down Macs is either "clear" or "inevitable" in my view.
[1]: There are some identifiable explanations as to why iOS is so locked down whereas the Mac isn't, but let's talk about that some other time.
If you want a reason, efficiency of maintenance and RD departments.
If everything works exactly like iOS you save $$$$$$$, added benefits you can charge enterprise licensing fees to get access to your sdks and dev tools. And if you have e.g. a luxury market cornered you can command those sorts of prices.
This is exactly Apple's playbook, I don't know why anyone would expect them to do anything different...
Not as the primary boot OS, perhaps, but it will work under virtualization. The M1 chip supports virtualization, and Apple has a new hypervisor API in Big Sur:
As I mentioned in a previous comment, 2b should be easier on the M1 because it's inside a real computer with debugging tools and we can probably fuzz the hell out of it, among other things. (Famous last words.)
1b and device drivers seem to me like the biggest obstacles.
Parallels/VMWare (even Docker maybe) on Apple Silicon Macs will be the first desktop class Linux ARM computers in wide circulation. Certainly putting a popular and performant package for the same software stack as the Rasperry Pi should help the Raspberry Pi project right?
I don't understand why you think Apple specific components matter, surely Linux developers will ignore those and focus on the cpu side.
Partially because if you use Xcode and Swift the CPU is mostly irrelevant. If you don't use those tools you'll need to care more about the CPU.
And partially because Apple built their own silicon, which means there could be secret instructions or instructions that work slightly differently than expected for ARM. I don't know how true this is for the M1 but it's been one of many issues holding back non-Apple compilers and Linux on Apple mobile devices. Having the M1 on a real desktop computer with deep debugging tools may mean we can fuzz and fully characterize the M1, which was harder to do on iPhones.
I don't think we'll see much change in consumer apps as you still have the Mac -> Linux jump. We might see fewer ARM-related bugs, but were there many of these anyway?
Where I think it's a game-changer is in Docker images. A lot of projects only build x86_64 images, M1 means they'll build ARM images as well
Virtualization tools and host OSes will probably see a huge boost in ARM support as well, but the Raspberry Pi is a bit too limited to really take advantage of these improvements.
> Open source software builds for ARM? Most certainly.
What? Plenty of open source software already builds on Arm.
Honestly, it feels like people here forgot that Arm is a processor architecture that has been around since 1985. Apple just happened to put one in their computer 35 years later.
So far, I can’t buy any other ARM laptop (I can build a PiTop, but that’s a toy, not a modern computer suitable for work). So yes, high performance ARM laptop in the general availability _is_ a big deal.
I agree, it's highly unlikely they would give away their competitive edge. A lot of their speed-ups may even come directly from dedicated silicon anyway, and that would likely be under lock-and-key for quite some time (until hackers of the future reverse engineer the M1).
(until hackers of the future reverse engineer the M1).
They wont find anything of interest. The M1 is just a well designed low power mid-performance tier chip. There's no magic when you compare a power efficient arm chip to an x86 chip in the same class.
And don't forget that apple has a closed ecosystem so they can build whatever the hell they want without worrying about the technical inertia and legacy baggage the PC platform as a whole is completely built upon.
I imagine the hackers of tomorrow will reverse engineer the M1 for the same reason they reverse engineer the chips of yesterday - nostalgia. In any case this will be an interesting note in computing history.
What I feel like a lot of people are ignoring here is that this was a speedup from an underpowered macbook line....
They beefed up core caches a bunch, which likely has a lot more to do with the speedups than any special silicon tricks...
People are also ignoring that they have a lot of software infrastructure based around virtualization and auto optimization...its like if the JVM was running at kernel level on a jvm optimized chip with days to perform optimization...of course you would expect that to be blazing fast. Compared to the horror show in Intel land where you have to compile in special support for advanced instructions...
I believe that yes, that is true. The builds are ultimately made by developers, developers want software to run on their own machines, developers will buy M1 Macs if only for the novelty factor.
TL;DR - Yes, but after few years. And will be indirect.
So - before M1 announce ARM market was reserved for battery devices when huge limitation is power for them. Performance was important, but most important is power consumption.
There was also some niche server-side ARM like Marvell ThunderX, Qualcomm Centriq or Amazon Graviton.
Actually Apple acquire P.A. Semi company in 2008 and before that they're known for PWRficient processors.
Now M1 release shock whole industry.
First PC manufacturers like Dell or HP - but for now they're tied with vendors as Intel and Microsoft.
Second Cloud operators like Digital Ocean and Google - only Amazon have their own ARM CPU.
Third OS vendors like Microsoft - they're having a Windows RT in past and need to revive it ASAP.
Forth are CPU vendors like Intel, AMD that providing x86 and Broadcom, Qualcomm that are ARM - because first can seen how their x86 product line is outperform from ARM products. And other can seen how even their top ARM products are outperform from niche player as Apple.
In result - expect shortly a HUGE investments in post-x86 for different chips architectures and as result RPi will be improvement. But not today!
I think it depends if Apple M1 and Raspberry Pi ARM are compatible. I can imagine that open-source projects will work on trying to get it going under ARM so it can be used on Apple Sillicon Macs as you can't emulate x86 on them.
A side-effect of the above is that the projects will also support other ARM-based chipsets, such as Raspberry Pi's
71 comments
[ 4.1 ms ] story [ 107 ms ] threadIt'd be awesome if Apple would let Raspberry Pi use their M1 chips, but clearly that's never going to happen!
What could be very interesting though is emulating a Pi on an M1 Mac in virtualisation.
I just switched to the starship shell prompt on my mac, for example, and I tried to install it on my Pi as well, but there's no prebuilt binary for Pi, and after an hour or so I gave up trying to build it myself. :P
Also, for a large number of these devices, they run Java-ish code on a Java-ish VM.
Even if it does work, there'd be little use in it. Hackintoshes are popular because they offer performance beyond what you can buy for a reasonable price as a consumer. Alternative ARM devices are nowhere near as fast as M1, so that use case disappears completely.
There's also the bootloader issue. On x86 and x64 the boot process has been standardized into either BIOS or UEFI mode. On ARM there are standards comparable to UEFI, but most chip vendors have their own custom bootloader code to boot an OS. Most chipsets are compatible with Android or Linux but there's only one manufacturer who develops bootloaders for the macOS platform.
Of course, this will apply to VMs only (for now at least). https://alephsecurity.com/2019/06/17/xnu-qemu-arm64-1/ was a good starting point for me.
Apple have ARM IP for instructions. So Apple Silicon is 100% ARM compatible.
They can only be used in Accelerate.framework or in the kernel, which checks and is able to work without them.
https://www.cnx-software.com/2018/11/25/benchmark-x86-boards...
But they do support clang.
Can they make an Air competitor? As far as I understand, not today.
For macOS, the support revolves around Xcode. Cross-compilation support is Apple-specific and won't benefit Linux. CPU architecture is abstracted away in macOS as much as possible, so average developers won't think much about ARM support.
Where Apple wants developers to tune for M1 specifically, is their proprietary frameworks for ML acceleration and Metal, which don't benefit anyone but Apple.
At best there may be some halo effect from proving that ARM can be as fast as "real" desktop CPUs, and it's not just the low-end slow Qualcomm chips. That might legitimize running ARM on servers, but Pi is neither high-end desktop nor a server platform.
I don't see 2a happening, and let's hope for 1a and time.
Surely the Linux kernel does not support these things now, but there's only baseless speculation that Apple would actively lock this down.
> They are slowly but surely moving towards not being apple to run anything not Apple on OSX as well.
I would argue that both of these statements are completely baseless, and the second is actually actively argued against by Apple.
I'll be the first to say that their handling of iOS things is horrible, and I would buy iPhones and iPads if they were a more open platform, but the world is more complicated than "Apple is evil" and their handling of iOS has no bearing on the Mac.
In my view you can only believe Apple will lock down the Mac if you somehow view them as an irrational ideological opponent, not simply a company that wants to make money by selling computers. Since you say you don't care what Apple themselves say towards this, I can't escape the impression that you might actually already view them in this way. If so, there's not much we can talk about.
I really would love nothing more then buy the new Apple Arm Macbook Pro but I can't risk investing in this ecosystem when, to me, it's quite obvious where Apple stands on this.
> I rather watch their actions.
And which actions are those? Gatekeeper and the Apple T2 are not enough to make the Mac not an "open computing platform", let alone something close to iOS. I'd argue they're not even on the way there, just like Windows SmartScreen isn't on the way there. And note that the T2 is even gone from Apple Silicon Macs.
Apple deserves all the added scrutiny in this area because of their attitude on iOS [1]. But there's absolutely no reason to believe that Apple's direction towards locking down Macs is either "clear" or "inevitable" in my view.
[1]: There are some identifiable explanations as to why iOS is so locked down whereas the Mac isn't, but let's talk about that some other time.
If everything works exactly like iOS you save $$$$$$$, added benefits you can charge enterprise licensing fees to get access to your sdks and dev tools. And if you have e.g. a luxury market cornered you can command those sorts of prices.
This is exactly Apple's playbook, I don't know why anyone would expect them to do anything different...
Not as the primary boot OS, perhaps, but it will work under virtualization. The M1 chip supports virtualization, and Apple has a new hypervisor API in Big Sur:
https://developer.apple.com/documentation/virtualization
1b and device drivers seem to me like the biggest obstacles.
As far as I know there Linux driver support for Intel Macs is abysmal, due to lack of support from Apple.
I would be shocked if ARM Macs, which will probably be even more locked down, were more open somehow.
I don't understand why you think Apple specific components matter, surely Linux developers will ignore those and focus on the cpu side.
And partially because Apple built their own silicon, which means there could be secret instructions or instructions that work slightly differently than expected for ARM. I don't know how true this is for the M1 but it's been one of many issues holding back non-Apple compilers and Linux on Apple mobile devices. Having the M1 on a real desktop computer with deep debugging tools may mean we can fuzz and fully characterize the M1, which was harder to do on iPhones.
Where I think it's a game-changer is in Docker images. A lot of projects only build x86_64 images, M1 means they'll build ARM images as well
Virtualization tools and host OSes will probably see a huge boost in ARM support as well, but the Raspberry Pi is a bit too limited to really take advantage of these improvements.
Will Apples move to Intel mean better support for the PC?
Answer: No.
What? Plenty of open source software already builds on Arm.
Honestly, it feels like people here forgot that Arm is a processor architecture that has been around since 1985. Apple just happened to put one in their computer 35 years later.
They wont find anything of interest. The M1 is just a well designed low power mid-performance tier chip. There's no magic when you compare a power efficient arm chip to an x86 chip in the same class.
And don't forget that apple has a closed ecosystem so they can build whatever the hell they want without worrying about the technical inertia and legacy baggage the PC platform as a whole is completely built upon.
I imagine the hackers of tomorrow will reverse engineer the M1 for the same reason they reverse engineer the chips of yesterday - nostalgia. In any case this will be an interesting note in computing history.
They beefed up core caches a bunch, which likely has a lot more to do with the speedups than any special silicon tricks...
People are also ignoring that they have a lot of software infrastructure based around virtualization and auto optimization...its like if the JVM was running at kernel level on a jvm optimized chip with days to perform optimization...of course you would expect that to be blazing fast. Compared to the horror show in Intel land where you have to compile in special support for advanced instructions...
So - before M1 announce ARM market was reserved for battery devices when huge limitation is power for them. Performance was important, but most important is power consumption.
There was also some niche server-side ARM like Marvell ThunderX, Qualcomm Centriq or Amazon Graviton.
Actually Apple acquire P.A. Semi company in 2008 and before that they're known for PWRficient processors.
Now M1 release shock whole industry.
First PC manufacturers like Dell or HP - but for now they're tied with vendors as Intel and Microsoft. Second Cloud operators like Digital Ocean and Google - only Amazon have their own ARM CPU. Third OS vendors like Microsoft - they're having a Windows RT in past and need to revive it ASAP. Forth are CPU vendors like Intel, AMD that providing x86 and Broadcom, Qualcomm that are ARM - because first can seen how their x86 product line is outperform from ARM products. And other can seen how even their top ARM products are outperform from niche player as Apple.
In result - expect shortly a HUGE investments in post-x86 for different chips architectures and as result RPi will be improvement. But not today!
PS: Do you remember Russian CPU Elbrus? It's VLIW! https://www.youtube.com/watch?v=PUNJ_tkq2hk
A side-effect of the above is that the projects will also support other ARM-based chipsets, such as Raspberry Pi's
It's just another example of why non-portable code is silly.