This is an odd place for Microsoft to be, on ARM, both Linux and MacOS have much more complete suites of software available than Windows. Obviously both Windows and MacOS support emulation of their respective x86 platforms, but in terms of native software, Windows is kind of a distant 3rd place.
I guess this opens up the chance JetBrains will point IntelliJ and PyCharm over.
As much as I'd like it to be I don't think Linux is a serious desktop contender for most people, so Microsoft is just in second place - and it's not that distant yet, since the Apple transition has just started.
But of course the real (and perhaps obvious) difference is that Apple is much more strict about its ecosystem, having decided ARM will definitely be a thing and developers need to follow to stay relevant.
The Windows version is "maybe there will be ARM devices one day, maybe". That's not nearly as convincing.
I believe the most convincing thing for developers (besides rewards like promotion and filters in the store, which MS badly sucks at) would be a wave of serious ARM devices coming out in the very near future. The longer it takes the slimmer the chance that Windows on ARM will really catch on.
> As much as I'd like it to be I don't think Linux is a serious desktop contender for most people, so Microsoft is just in second place - and it's not that distant yet, since the Apple transition has just started.
My point here is:
- A huge chunk of Linux software (desktop or server) has been ported to ARM or will soon be.
- A huge chunk of MacOS software will likely be ported within the first few months of launch.
- A very small percentage of Windows software has been ported to ARM. Even the usual Windows strongholds: Games and corporate software have poor support for Windows ARM. Windows x86-64 bit emulation is missing (or at least was at launch) so a significant amount of pro software and games won't run even under emulation.
> The Windows version is "maybe there will be ARM devices one day, maybe". That's not nearly as convincing.
Exactly this. Microsoft has had so many false starts on platform shifts they have a hard job selling this.
> Windows software written in .NET and Java has little to worry about what CPU is being used, and there is plenty of it to chose from.
Considering many/ most pro apps like Photoshop are not written in .NET or Java, it is a significant concern. Likewise games—a category of software Microsoft has long dominated—are not generally written in Java/ .NET. Likewise, huge chunks of legacy corporate software is not very portable.
> Also outside HN bubble right there in the real world, macOS desktops are about 8% across the whole world. It doesn't really matter what CPU they have.
I wasn't talking about unit sales, I was talking about how much software the platform supports. Regardless of whether the Mac has 3% or 99%, there is going to be a better selection of software available for Mac on ARM in 6 months than for Windows ARM.
Sure they are, most modern Windows software is a mix of .NET and C++.
As for modern Windows programming, UWP has been able to target ARM since ages.
Yeah, not everything will be available, then again it doesn't matter how much software is available, if only a subset of those 8% of the computing world population is going to get it.
At least for right now. We'll see how things look in a few years. If Intel can't get back on track, ARM might actually surpass them and that's a very good reason for Microsoft to be looking to support ARM.
Lack of 64bit-only pro software isn't matter for 2019-2020 because lack of SoC performance. Possibly MS support 64bit emulation in time for SoC performance improving.
You can play the c++ version of Minecraft on the Surface X, however you couldn't play the Java version. Maybe the openjdk can fix this problem but I'm not really optimistic.
>As much as I'd like it to be I don't think Linux is a serious desktop contender for most people, so Microsoft is just in second place - and it's not that distant yet, since the Apple transition has just started.
I think market evidence points to the contrary. The Raspberry Pi is a fully fledged Linux Desktop, it's running and marketed with full fledged desktop software. Last I checked 25 million units have been sold.
It's use/sales far outstrips Windows RT or Surface Pro X which from what I know are the only current uses for Windows on ARM.
So yes I think Windows is in a clear 3rd place on ARM architectures.
> The Raspberry Pi is a fully fledged Linux Desktop,
I'm not sure I agree with this, lots of Pis are sold for projects which don't involve use as a desktop. In fact—from what I've seen—only a small percentage of Pis are actually used as day-to-day computing devices.
But in addition to the Pi, there is Pine64 which is exclusively sold as a "Desktop" platform with both laptops and workstations.
But I was talking more about the number of apps available on the platform than the number of units sold.
Software support for Windows ARM is a bit of a crapshoot which makes it hard to estimate what's out there.
It may not majority be used as a desktop, but it is marketed as such. You go to the raspberry pi store in Cambridge, and the first thing you see is it's use as a desktop.
The use cases for the Raspberry PI is ridiculously varied which I think reinforces it's application support relative to Windows on ARM.
I have seen it used for openstack development, as a desktop, home theatre pc, pihole, nextcloud instance, emulator etc... I haven't really found software that I can't just install/use.
Can you say the same for any windows on arm deployment? Especially if they are only just coming out with mainstream support for OpenJDK and Electron support.
In fact the alternative uses for the Pi are arguably as interesting/ important to its significance as a platform. A lot of little side projects which the Pi gets used for now used to be low end Windows boxes.
>I think market evidence points to the contrary. The Raspberry Pi is a fully fledged Linux Desktop, it's running and marketed with full fledged desktop software. Last I checked 25 million units have been sold.
That's a statistical error level compared to the number of PCs in the world.
And even the premise is wrong. The "Raspberry Pi" is not bought as a "fully fledged Linux Desktop" (whether it's marketed as such or not), but used mostly for special utility purposes, from automation and DIY experiments to multimedia servers and such...
Even if you add all Linux desktop machines, it's like 2% or something...
We aren't comparing it to the total number of PCs in the world and that marketshare relevance. I am sure there aren't particularly accurate statistics for that usage anyway.
This is a comparison between Linux on ARM and Windows on ARM. Not against Windows vs Linux as a whole. I assume this is in the context of future consumer desktop platforms on ARM hardware. In that context, OEMs who want to release a functional desktop product with ARM chips would find it a lot easier/appealing with ARM than on Windows at present.
In that context, Linux on ARM is vastly ahead of Windows of ARM.
My argument is that the total number of raspberry pis being used a Linux ARM desktop outstrips the amount of Windows ARM desktops (which are composed of surface RT/X tablets).
Well, we weren't talking about the desktop, were we? Especially when Java is involved. (Unless, of course, it is Java code development, in which case Linux is still a better platform anyway.)
Uh, what? Java started as a write-once-run-anywhere platform for applications. Java gained popularity as a browser plugin for richer UIs. Significant amounts of enterprise and in-house software are written in Java using AWT/Swing, SWT, etc.
I'm not concerned about the server. If the performance were good and Microsoft's built in Narrator screen reader worked well with vscode I could use an arm computer for all my hobby programming now. I don't know how well Narrator works with vscode but unfortunately as far as I can tell NVDA is not being ported to arm. Yet another example of the lack of software. I'd consider getting a cheep Windows ARM laptop to investigate porting it but it looks like everything is over $500.
> Obviously both Windows and MacOS support emulation of their respective x86 platforms, but in terms of native software, Windows is kind of a distant 3rd place.
Much (most?) new Windows software these days is written in .NET and might just work out of the box, since that's technically speaking what .NET is supposed to enable.
(With the obvious reservations about platform specific quirks. I've ported my fair share of code to different platforms, and now it's often not that simple)
There is also a lot of legacy 32 bit code and industry specific tools which are getting left behind. Plus a lot (most?) of Pro tools and games use C++ or something a bit lower level.
I know Adobe is dragging their feet supporting Windows ARM and there is very little gaming support for it either. Both Adobe and Unity have announced "Apple Silicon" ports, Adobe has been dragging their feet on Windows ARM support and I don't even think Unity has announced they will migrate to Windows ARM.
Transparent DBT for userspace programs has been a thing on Linux the whole time, more or less. QEMU could stand to do a lot better performance-wise, though, for programs that actually care about that.
Off topic: I have a scanner with excellent x86 32/64 bit linux drivers.
Has someone come up with a smooth way to use them on ARM? (The leading contender is a qemu chroot with the scanner gui and driver installed, but that sounds hard to maintain over time).
I really want to just link the x86 .so into an arm binary, performance-be-damned.
Sorry, now I see you wrote scanner and not printer so here is my response to printer :
----
You could put it in a container, and connect it with CUPS. CUPS is network-transparent and there should be nothing stopping you from running it in a container.
It is not unheard of to use QEMU userspace DBT in containers[0].
If your scanner drivers hook into SANE, I think saned supports sharing a local scanner over the network, so you could set that up in a container, similar to setting up CUPS in a container for printer drivers. Here's the document for setting that up: https://wiki.debian.org/SaneOverNetwork
A container is nice because you can also be sure that the scanner container only exposes the saned socket, and has no other network access.
QEMU is bordering on unusably slow even for applications that are not performance sensitive, mostly because of memory ordering issues. TSO is not really easy to do dynamically.
Yeah, my primary use case for it has been running proprietary utilities to inspect/operate hard disks, and things like that, which may only be available as statically-linked ia32 binaries, potentially until the end of time.
There is a lot of performance left on the floor by real-time-only DBT when applied to binaries which do not jump into dynamic memory at all. QEMU is also, in my opinion, too general-purpose to be efficient. I think high-performance SBT and DBT is crucial to the adoption of new ISAs, it should maybe be something RISC-V International/The Linux Foundation puts up a bounty for (along with native ports of popular JITs like v8 and HotSpot).
Microsoft is a software producing company. It makes sense for them to be able to support their software on every hardware/OS that is good as a business decision. The fact that they produce an operating system as well, it's irrelevant in current landscape. I don't get your oddness.
For me, and I suspect for many people, the singular reason we used Windows in the 00s was the fact that Windows was the platform with the most software support. The Mac and Linux were secondary and tertiary platforms respectively for most developers.
Things have changed a lot since then, but to me, seeing Windows being the platform which has the least software support, even in this limited scope, is a sign of how much of a reversal Windows has seen.
> Windows being the platform which has the least software support
What a strange universe you must inhabit. Windows still utterly dominates the software landscape except in web stuff. I have yet to work at an org that didn't have a dependence on many pieces of software that are exclusively Windows.
> I have yet to work at an org that didn't have a dependence on many pieces of software that are exclusively Windows.
You do know we are talking about Windows on ARM here right?
I haven't said that every time I've been talking about this, but that's the context, Windows on ARM.
> Windows still utterly dominates the software landscape except in web stuff.
Again, Context. Windows on ARM doesn't dominate anything. That's why I said "even in this limited scope" right after the phrase you quoted. I figured folks would recognize we were still on the same topic.
I wouldn't bet against MS regarding backward compatibility. I'm sure that everything running on x86 runs or will soon run on ARM. Perhaps a little slower yes, but your average consumer will be unaware of the difference beside that, so for every practical purpose Windows will have 'more complete suites of software available'.
There's one Windows software sector that this is not good enough for - games (really care about performance+latency, unlikely to ever port to ARM), but that sector is the least likely to want to switch to ARM in the first place. Gamers will go Windows+AMD anyway.
The bigger problem for Windows-on-ARM is that non-Apple desktop-class ARM processors are right now rather weak, and that affects all applications, even ported apps.
> I wouldn't bet against MS regarding backward compatibility. I'm sure that everything running on x86 runs or will soon run on ARM.
Oddly, Microsoft has 32 bit x86 apps running on ARM, but 64 bit x86 apps are broken. More or less exactly the opposite of Apple in terms of legacy software. This means there are some pretty notable holes in the Windows ARM Pro software scene -> Adobe being the biggest, most obvious.
The message from Apple is "Everything that runs on Catalina runs on the new Macs", but software which has been ported will run best. The messaging from Microsoft is much more nuanced.
> The bigger problem for Windows-on-ARM is that non-Apple desktop-class ARM processors are right now rather weak, and that affects all applications, even ported apps.
This is why Apple can afford to go all-in on ARM while Microsoft has to tap-dance back and forth between the two platforms.
>Oddly, Microsoft has 32 bit x86 apps running on ARM, but 64 bit x86 apps are broken.
It has been argued on HN that the reason was x86_64 patents that will very soon expire. Once that happens, Windows-on-ARM is very likely to have x86_64 emulation as well. Besdies, 99% of Windows software is available as 32bit.
The software sectors that don't will either never port old stuff (games) or will port anyway for Mac and have an easy Windows port as a result (e.g. Adobe).
>This is why Apple can afford to go all-in on ARM while Microsoft has to tap-dance back and forth between the two platforms.
Microsoft is mostly a software company, rather than an hardware one. It doesn't matter to them on what processor type you run so long as it's their software. I suspect the biggest reason for focusing on ARM isn't Mac, it's Azure.
Game developers have been porting their games to ARM for long time now. Sometimes, like GTA San Andreas, even for windows ARM, but these days the platform is usually iOS, Android, or Nintendo Switch. Historically there were others, PS Vita, Nintendo DS, they all had ARM CPUs.
The context was referring to existing software libraries, of course it is technically possible for new titles to have an ARM version. Existing games are rarely supported, some popular ones sometimes get a 'remake' or a 'remaster' which then might port them, but often games are left as is.
> I'm sure that everything running on x86 runs or will soon run on ARM. Perhaps a little slower yes, but your average consumer will be unaware of the difference
Windows-on-ARM already has 32-bit x86 emulation — and it's slow as molasses. Believe me, people do notice the slowdown.
But Microsoft has everything to gain by upping the performance to match what macOS is doing with Rosetta 2, so it's definitely a space to watch closely.
Apple's leg-work on the lead up to this migration is really standing out here. By deprecating 32 bit app support over the past ~2 years, Apple only needs to emulate 64 bit x86. For Microsoft, 32 bit support is still more important than 64 bit support, but big chunks of Windows applications want 64 bit support as well. Microsoft has had one foot on both sides of the 32/64 bit divide for years and it's making this migration a lot tougher.
Did I miss a beat and somehow thousands of developers have ported their apps to Windows ARM?
Last I heard Adobe only had a few tools working on the ARM version of Windows and only a few other developers were onboard.
From the sounds of it, when Apple Silicon goes live, there is going to be a pretty big selection of native apps (Plus they have iPad/ iPhone apps). The fact that Windows ARM didn't support emulating 64 bit x86 out the gate didn't help either since a lot of pro tools are 64 bit.
You're comparing two different timeframes - an expectation for what Apple may have when it launches, compared to Windows-on-ARM has today. That's not reasonable.
Most likely, everyone who will port their software to Apple ARM will also port to Windows ARM at the same time (same application core).
Isn't that because Microsoft locked Windows 10 on ARM down and forces you to use the Microsoft store? There are no competing stores on Windows on ARM by design.
Windows on ARM was Store-only back in Surface RT days. It's not the case with the more recent take that's used in devices sold today. Now, they come out of the box in S Mode, which is Store-only (although the store now supports desktop apps, unlike in RT); but you can easily switch that off, and then it's as open as Wintel.
This really depends on the implementation, which is a number of factors ranging from the specific ARM CPU, the fidelity of the emulation environment, and possible hardware acceleration. Apple has the latter and compares well in the first two, so I think we're going to get quite good results out of Rosetta.
Depends on the ARM processor and which x86 CPU to compare with. For example, a high end ARM CPU translating x86 code could compare well against an Intel Atom.
Okay, follow up then: Given a high-end arm chip, what would be a comparable intel x86 chip with similar performance, without either chip using any emulation? Is there a high-end ARM chip you could recommend I lookup and find benchmarks on something like Geek Bench?
Emulation performance can vary drastically depending on the application. Some programs might run with unnoticeable penalties, while others run dreadfully.
It's not just about having a suitable CPU though, it also relies on a good software layer. And there are many factors such as whether you're hitting cache or not.
From what I've seen online so far, the binary translator from Apple, Rosetta 2, seems to have promising technology. But we won't know until we see the new Apple Silicon based Macbooks.
My daughter has a 1-year old iPad mini. My own modest gaming rig has a mid-range 2-year old i7 (and an SSD & 1050 ti video)
Geekbench results for single-core performance are pretty much identical, though I win out by a wide margin on multi-core and video benchmarks.
But forget about benchmarks, here's a more practical example: fortnight loads in about 15 seconds on the ipad. For me about 45.
It's possible the graphics are lower quality on the ipad, though I can't tell the difference. Or maybe they have to optimize a lot more for iPads. Fortnight updates on the iPad, after downloading, also takes minutes while mine takes about an hour. I look forward to much less expensive arm chips coupled with a dedicate GPU, especially if it drives developers to write more optimized code.
In fact, this fortnight difference might be a case study in just how much can be achieved by optimizing. 3-5 year old phones can run Fortnite.
With Apple Silicon being implemented on ARM architecture as well, we are seeing a major shift to ARM in general. I’d expect major OS makers to accelerate ports to ARM.... Linux should follow suit..... as hardware makers start tailoring platforms, we don’t want Linux locked out of the house.
Edit: My concern was that Apple or MS would have divergent hardware and other support with firmware variations in their “custom” implementations. Kinda like the hardware driver issues Linux has had for years, but now burned into firmware.
Theres been plenty of ARM support on Linux the issue if I am not mistaken is that ARM isnt a processor its a spec you license and manufacturers go from there so code between processors should be completely icompatible even within the same manufacturer. You see discussions about it on HN plenty of times. Theres plenty of ARM based devices out there though due to the rising popularity of SBCs. Then we have the Pinebook and similar devices.
> code between processors should be completely icompatible even within the same manufacturer
Hello,
Arm is explicitly managed to prevent such a scenario to happen. Where things can and do diverge is the boot mechanism and peripherals, even if it has been getting better with time. (Arm servers and Windows on Arm machines using UEFI + ACPI)
However, for user-mode code, compatibility is mandated and checked by Arm, even for designs not made by them. As such, don't worry about it.
That's true in embedded and mobile, but not the case in the server space. The platform has been standardized so that the same Linux ISO will work on any mainstream Arm server.
I'm wondering if the solution to this involves shipping more software via something like the AUR (Arch User Repository) rather than in binary packages.
It's not necessarily sane to maintain binaries for each and every device flavour, but as long as the code is reasonably portable & each manufacturer keeps their LLVM IR/JVM bytecode backends in order, that might be enough to overcome some of the pain.
I've always found Arch distributions to be more usable on ARM systems than Debian distros simply because they user-friendly ways of building & installing from source. Building from intermediate representation might be the right mix of obfuscation, performance, friendliness, and portability for the consumer space.
It's not really an issue on "desktop class" devices you want to run Linux on and similar to x86 in practice. When people say "modern ARM devices" they are always talking about 64-bit ARMv8. Of those available chips, there simply aren't many differences in terms of available ISA features. All of the "real" differences come down to microarchitectural ones e.g. Cortex-A53 vs Cortex-A55 or whatever. But Linux distros don't need to maintain builds for all of those uarchs, anymore than Debian needs to maintain separate builds for "Haswell vs Skylake vs Zen2" on x86. You can of course compile from source and make this distinction yourself. But it's basically par for the course, like it has been in the x86 world for a while.
The reasons most ARM devices require special "builds" for $YOUR_FAVORITE_OS almost entirely comes down to bootloader/peripheral nonsense. There wasn't (until recently) any standardized way to discover devices attached to your favorite ARM chip, nor any standard boot protocol, like we have in the x86 world. Therefore every device needed its own little description of the attached peripherals and (often) needed a little support in the bootloader -- uboot -- to accompany it. Therefore there are normally device-specific kernel/bootloader packages in your favorite distro, and specific installation instructions, but not every package needs this treatment. Once you install the distro, you can use the same ARM userspace binaries/packages as any other device, more or less.
However, ARM is now settling on ACPI/UEFI like in the x86 world to handle booting and peripheral discovery in a generic manner. You can, for example, use UEFI/TianoCore on the Raspberry Pi 4 today, and boot generic ARMv8 distro images of your choosing, just like you do with x86 systems.
I think providing source based installations should be a secondary approach to distros that do provide prebuilt binaries. The benefit to prebuilt binaries is basically you only need to download it, not wait hours and hours for sources to build, plus no need to pull down every developer only dependency.
Windows has been available for ARM since 2012, called Windows RT back then. macOS is actually the last of the popular operating systems to port to ARM, not the first.
As usual with Apple's products, Apple is hardly ever the first one to do thing X. What they are is that they are usually the first ones to do the thing X so well that the public will adopt it. And that's what matters in the end, not who was first.
The big differenc is, following Apple's announcement, that they want to avoid that the users even realize there is an Arm CPU inside.
My dad had a Surface RT a few years ago (I cannot recall how long exactly). But you definitely did realize something was "different" with this thing.
I think Apple has a better chance at achieving this broad acceptance than MS has because they have a lot more control over their ecosystem and hardware. People actually seem to use their frameworks for building apps, for App Store as well as direct downloads. Unlike Microsoft who still has not managed to convince developers to move to UWP apps.
I actually don't hate using the Mac App store on my machine, but I haven't used the Microsoft Store ever since I first tried it. And for lots of more casual users, they probably actually won't realize that there is a difference between the architectures.
iOS, which is the macOS/OS X userland and kernel with different higher level development APIs and a few things toggled, has been ported and running on ARM for at least 5 years before 2012... (more if we include the iPhone development period).
Apple was the first to ship Arm 64-bit hardware back in 2013. For the Arm macs, they waited until everything was ready, with them being competitive across the whole range.
Microsoft instead cornered the laptop/tablet with integrated modem for Windows on Arm (64-bit), which allowed them to ship much earlier.
Lots of software works on ARM on Linux... but it doesn’t always work as well as on Intel. I think there’s quite a lot of work to be done to get various parts of a complete distribution working as well as we’d like for server and desktop usage, outside of the more limited embedded role it’s already widely deployed in.
What types of "doesn't work as well" are you thinking about? My understanding of where ARM "doesn't work as well" is something like these areas:
* The underlying code is relying on x86 features or is x86 ASM. In that case ya... this is going to be a bit rough - but is a super minority, especially for use cases where you'd want to use ARM
* The runtime or compiler hasn't been ported to ARM yet. For compilers, I don't think this is a problem - I think both clang and gcc are completely ready to go for armv7 and arm64. Go is good to go too. Runtimes is a bit more dodgy, but all the major (Java, C#, Python, Ruby, Perl, Javascript/Node) languages and runtimes are just fine. Maybe the only one out is rust, which doesn't have ARM as Tier 1 supported (but should just work) yet.
* Hardware support. There may not be good open source drivers for various ARM specific hardware blobs.
There's a long tail of various issues to sort out and "language runtimes that have all the kinks ironed out" is definitely one of them. But I think that's just always going to be the case for any alternative trying to get up to speed with an incumbent player that has a decades-long head start. And most of it works fine today, anyway. Micro optimizations in HotSpot or whatever isn't what's holding people back from desktop ARM machines. (If any language could make a difference here, I'd actually argue it's JavaScript being optimized because it's vital to web browsing, but luckily that got sorted out years ago thanks to mobile handsets.)
Plenty of things work very well and I'd think most people would rate those working as far more important than small compiler tweaks. NVMe, GPU support etc is vastly more important to me than compiler micro-optimizations, for instance, because those actually make day to day developer usage viable. No amount of compiler optimizations will make SD cards fast. And today, you can boot generic Linux images for whatever distro, using UEFI, on high-speed ARM systems, with fully working desktops -- including working FOSS GPU drivers, full web browsers (with working javascript JITs), and high speed storage. So I think it's shaping up pretty nicely.
By missing intrinsics do you mean you get an error if you try to use the intrinsic, or do you mean the compiler fails to map the intrinsic to the fastest instruction/instruction sequence?
x86 has much stronger guarantees about memory ordering compared to ARM [1]. Maybe this comes under x86 features, but multithreaded software will not work if assumptions of memory ordering guarantees are made.
My naive understanding is ARM devices traditionally use a static, unchanging "device tree" specification to bring up hardware on boot. There's a project for implementing UEFI firmware for the Raspberry Pi - as one ARM device - so that you can take any unmodified (ARM-built) Linux that would boot off of EFI and it will Just Work (tm).
Actually what I've been doing is using my wireless router (openwrt) to serve pxe images. So the rpi sits without an SD card. It's powered via Power over Ethernet (PoE), is advertised a pxe server, gets the initial uefi & ipxe binaries, then I can boot from an image off Github or one served locally. ipxe just adds another layer of indirection for expanded fun.
> major OS makers to accelerate ports to ARM.... Linux should follow suit
Have you heard of Raspberry? Even before it was released there were almost all of Debian packages in ARM, so Raspberry had it easy, they just took something that already worked.
And it was years ago.
"In the late 1980s, Apple Computer and VLSI Technology started working with Acorn on newer versions of the Arm core. In 1990, Acorn spun off the design team into a new company named Advanced RISC Machines Ltd.,[30][31][32] which became Arm Ltd when its parent company, Arm Holdings plc, floated on the London Stock Exchange and NASDAQ in 1998.[33] The new Apple-Arm work would eventually evolve into the Arm6, first released in early 1992. Apple used the Arm6-based Arm610 as the basis for their Apple Newton PDA".
And for over a decade they have been investing in ARM (for iOS uses), and later inventing and designing their own ARM CPUs, so there's that. Plus lots of work on LLVM for ARM.
Apple actually worked on the Arm6 architecture along with Acorn in the late 80's/early 90's. In this instance, it's fair to say that they did invent this and argualbly showed interest in the platform before anyone else.
I’m probably missing sufficient context but this quote suggests a more involved route
[0]
DEC approached Apple wondering if they might be interested in a high-performance ARM, to which the Apple engineers replied "Phhht, yeah. You can’t do it, but, yeah, if you could we'd use it."
I assume they're referring to [0] which notes that ARM Holdings was co-founded by Acorn, Apple and VLSI. I don't think the comment in that StrongARM article is unreasonable given the state of technology at the time - as a bystander it seems like ARM competing with x86 in performance has only really become possible in the last few years.
I guess this opens up the chance JetBrains will point IntelliJ and PyCharm over.