Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Undocumented arm64 ISA extension present on the Apple M1

gist.github.com

Post reply on HN
Print view View original

171–180 of 202 posts

Re: Undocumented arm64 ISA extension present on the Apple M1

#171

Post by tzs »

rgovostes wrote: post #93
monocasa wrote: post #71

Earlier quoted context omitted.

They did that, in part, because they were subject of one of the first GPL enforcement actions, originally being unwilling to open source their objc GCC frontend. They being Nextstep at the time, but there's not a huge distinction these days. Their investment in LLVM is very much an attempt to keep reproprietization on the table.

I absolutely believe that the investment in LLVM was justified to executives as a way to avoid GPL-licensed software, which Apple has long been allergic to. But it should be noted that the GPL violation you refer to was in 1989. Put in context, that was ~16 years before they started investing in LLVM, and they have done so continuously for the past ~15 years.

It should also be noted that GCC was not suited technically, by design, for what Apple wanted out of a compiler at the time.

The JIT stuff they were doing with image filters for Core Image and Core Video and the IDE integration they were doing in Xcode could not be done in GCC at the time regardless of licensing without making massive changes, which would not have been accepted upstream.

GCC at the time was intentionally designed and implemented to make it hard to use parts of it independently, such as just using the parser to make a syntax tree for your IDE to use for highlighting or suggestions, or using the code generator in a JIT.

There had been suggestions and patches to make GCC more modular and separable, but they were rejected because being more modular would make it easier for proprietary software to interact with GCC components.

It was only after LLVM and clang started getting widespread use that GCC became more open to the idea of it becoming more flexible like LLVM.

Re: Undocumented arm64 ISA extension present on the Apple M1

#172

Post by Jetrel »

simion314 wrote: post #76
user-the-name wrote: post #48

Earlier quoted context omitted.

> Apple can make tools that use the undocumented ISA, which they don't have to release to the public, potentially using it to develop applications with performance advantages that no one other than Apple can attain. Why would they? They sell hardware, not really software.

>They sell hardware, not really software. But they make more money from the Apple Store and the other services and they are always giving advantages to their own stuff on iOS like using private APIs or bypassing security rules .

It's starting to grow, but on any given platform of theirs, the overwhelming majority of their income still comes from the actual hardware, and the services revenue for that platform is maybe 1/6th or 1/8th of what they make from the hardware for it:

https://www.statista.com/statistics/382260/segments-share-re....

(within this, you probably want to break out 5/6 of the services revenue and tack it onto iOS, and then treat the remaining 1/6 sliver as applying to the mac).

This is honestly one of the biggest peace-of-mind things for being an apple customer, and it's definitely a big cultural trope within their support network as well. You pay your "union dues" by buying the hardware, and then "you're in". There's no money to be made after that fact, so there are an enormous number of small interactions after that that are fully trustworthy - for example, unlike many internet-ad-revenue companies, you're not worried about being profiled or having your info sold to advertisers. You're also not worried about "product collapse based on shaky revenue streams" - one thing that's always been scary about using various consumer apps is there are a fair number of programs out there that just have really shaky revenue models, so it's scary to commit to them because a lot of them eventually have to pivot, or sell out, or otherwise do something brutal to stay alive. When using some of apple's hardware, you know if it's selling decently, the business is stable and certain rugs won't get pulled out of under you.

Re: Undocumented arm64 ISA extension present on the Apple M1

#173

Post by legulere »

monocasa wrote: post #109
legulere wrote: post #107

Earlier quoted context omitted.

The way you put it non copyleft licenses are just there for bait and switch. I don’t know any case where that happened where there was outside contributions.

Oracle reproprietized all of Solaris, including the outside contributions up to that point. And I assume that Apple has support for these instructions this whole thread is about in their toolchains, so if that's the same version that's in xcode, reproprietization is already happening. Leaving reproprietization on the table is the whole point of non-copyleft open source.

Solaris was released under a copyleft license (CDDL). How did they do that. When I google it I find your comment as the first result.

Re: Undocumented arm64 ISA extension present on the Apple M1

#174

Post by ithkuil »

mhh__ wrote: post #95
ithkuil wrote: post #63

Earlier quoted context omitted.

2036, Apple Mill

Well, the people behind the Mill might not being around in 16 years time. That being said, I would really like to see the Mill make it to Silicon - even if it doesn't work in the end, it's much more interesting to me than RISC-V.

Patents will survive their retirement ;-)

I assume RISC-V appeal is because it's open and thus allows people to explore (proprietary) implementations while maintaining compatibility at the ISA level.

If I understand correctly you cannot do this with Mill either.

Their work looks very interesting, but I'm not drawn in writing an fpga implementation or work on a toolchain for it, since I know any success may be impeded by patents

Re: Undocumented arm64 ISA extension present on the Apple M1

#175

Post by floatingatoll »

gsnedders wrote: post #156
rodgerd wrote: post #150

Earlier quoted context omitted.

It's interesting, in as much as there's been a constant bickering around whether the GPL vs Apache license for GCC and llvm means anything; to date, there general view has been that there's no evidence of anyone using LLVM to build compilers with closed extensions that are not released to the community; this is perhaps the first case of that.

Is there any evidence that Apple has an LLVM compiler with these extensions, versus using asm blocks within the Accelerate library source? There's certainly prior cases of Apple shipping branches of LLVM (most notably adding arm64 support, which took about half a year to merge in upstream), but the mere existence of these instructions is little evidence of any branch?

I have heard of none, though I do not speak for others.

Re: Undocumented arm64 ISA extension present on the Apple M1

#176

Post by chx »

EricE wrote: post #65
mhh__ wrote: post #7

Earlier quoted context omitted.

In the bigger picture Apple aren't really documenting anything for their new toys, which is not the end of the world but is a huge step back for openness. There is - as far as I can see - no long-form documentation for M1 other than patents. I already refuse to own apple products so I don't really have any skin in the game, but consider that if microsoft were like this the blind eye would not be turned - buy our new…

Or maybe different people have different needs and don’t care if every device is “open”. The vast majority of people are not enamored with technology for technologies sake. These are tools. Does the tool do what I want with the least amount of friction? That’s what they care about. Also how does Apples stance on one product in any way change the device you are using to post in any way? Are Apple thugs coming to your…

> Are Apple thugs coming to your house destroying non-Apple tech? Of course not!

Reminds me of http://www.sandraandwoo.com/2016/06/09/0793-an-offer-you-can...

Re: Undocumented arm64 ISA extension present on the Apple M1

#177

Post by saagarjha »

gsnedders wrote: post #156
rodgerd wrote: post #150

Earlier quoted context omitted.

It's interesting, in as much as there's been a constant bickering around whether the GPL vs Apache license for GCC and llvm means anything; to date, there general view has been that there's no evidence of anyone using LLVM to build compilers with closed extensions that are not released to the community; this is perhaps the first case of that.

Is there any evidence that Apple has an LLVM compiler with these extensions, versus using asm blocks within the Accelerate library source? There's certainly prior cases of Apple shipping branches of LLVM (most notably adding arm64 support, which took about half a year to merge in upstream), but the mere existence of these instructions is little evidence of any branch?

No idea what the story is with AMX instructions, but Apple has been shipping an arm64e compiler for quite a while with changes that have not been upstreamed.

Re: Undocumented arm64 ISA extension present on the Apple M1

#178

Post by saagarjha »

giantrobot wrote: post #29
ericlewis wrote: post #3

Earlier quoted context omitted.

From what I can tell reading this: the Accelerate framework from Apple seems to use custom instructions possibly unique to the M1 chip but potentially similar to Intel AMX. Accelerate is, as I sort of understand it- a way to do advanced math in a very quick / power efficient way. It is touted as deeply integrated with Apple processors from the day it launched and (I think) even recommended to be used over SIMD and th…

Say hello to Function Multi-versioning [0]. You tell the compiler to build a version for each march defined in the attribute. When that function is called a quick CPU check (via CPUID) is performed and if there's a version specific to the current CPU that will run instead of the more general implementation. ICC has supported this for a long time and it's widely used in Intel's MKL. LLVM also supports FMV but uses a s…

Note that on ARM it is more annoying to get CPU capabilities as there is no straight cpuid equivalent.

Re: Undocumented arm64 ISA extension present on the Apple M1

#179

Post by saagarjha »

egsmi wrote: post #60
rwmj wrote: post #46

Earlier quoted context omitted.

If the compiler generates these instructions, won't old binaries break if Apple later make changes in the hardware? (For shared libraries it would be "ok" because the old binary could use the new library, as long as Apple didn't also break the ABI).

In theory that’s what bitcode protects against. Today, that doesn’t save binaries not distributed through the store or ones you compiled yourself via other compiler chains. It is possible to change that. One could even imagine it as part of the loading procedure. https://lowlevelbits.org/bitcode-demystified/

Bitcode wouldn't really help too much here.

Re: Undocumented arm64 ISA extension present on the Apple M1

#180

Post by andrewmd5 »

phone8675309 wrote: post #170
_-___________-_ wrote: post #152

Earlier quoted context omitted.

Releasing documentation makes them de facto public APIs. People will code against them anyway, apps will break when Apple changes the not-really-private APIs, and Apple will get blamed.

In that case they can do what they do for iOS apps - scan for the use of those instructions in any binary released through the App Store and refuse the update if they are used. Apple can't control random software people download off the Internet.

They absolutely can and actively do.
Post reply on HN