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

161–170 of 202 posts

Re: Undocumented arm64 ISA extension present on the Apple M1

#161

Post by megablast »

grishka wrote: post #125
supermatt wrote: post #79

Earlier quoted context omitted.

I just started getting into macOS and iOS development and the documentation is HORRENDOUS. Even the classroom educational material Apple put out is incomplete, outdated, and often completely wrong! Additionally, It seems to be impossible to compile anything in Xcode other than a hello-world without gettting undocumented warnings and (non fatal) errors logged, which, if you can find a matching thread on their forums,…

Why not pretend Swift doesn't exist and just use Objective-C instead? It's stable, it's well-understood, there's a ton of examples and docs everywhere and it hasn't changed much in a decade. I'm mainly an Android developer, so I've never made anything serious for the Apple ecosystem (only some tiny Mac apps for myself), but I just hate moving targets with burning passion. It's hilarious to look at all the "community"…

100%. I hate swift.

Re: Undocumented arm64 ISA extension present on the Apple M1

#162

Post by texse »

mlazos wrote: post #100

I’m thinking this is related to the machine-learning coprocessor. They likely expose this to developers through their ML API and don’t want to have to support this for external customers if it changes. Still this is a great find!

These instructions are not for the Neural Engine. That is a separate hardware block outside of the CPUs. Apple refers to this feature as "AMX" in their marketing documentation.

While AMX could be used for deep learning in a pinch despite the lack of support for common formats like fp16 and int8, I suspect Apple had some other use cases in mind as well. For example, 64-bit float support is expensive and generally useless for ML. However, they are useful (though not necessarily required) in problems such as bundle adjustment that may appear in the context of frameworks like ARKit.

Re: Undocumented arm64 ISA extension present on the Apple M1

#163

Post by colejohnson66 »

vbezhenar wrote: post #148
lukeh wrote: post #136

I see undocumented instruction extensions as a special case of private API: it buys Apple the freedom to change the underlying implementation in the future. As long as done in a manner that is not anticompetitive, I don't see the problem.

What’s wrong with releasing documentation clearly stating that those instructions are not guaranteed to be present in the future? Apple does not hesitate to break compatibility anyway.

Exhibit A is Windows. Microsoft publishing APIs and saying not to rely on them doesn’t work. Sure, Apple doesn’t care about backwards compatibility like Microsoft, but Apple will be blamed for breaking changes; They already are every time they change things.

Re: Undocumented arm64 ISA extension present on the Apple M1

#164

Post by josefx »

lumost wrote: post #142
toxik wrote: post #138

Earlier quoted context omitted.

Like private APIs, they ultimately transfer power from consumers to Apple. They surely do have documentation internally, they just don’t want to commit to anything.

it limits Assembler access and tools written against that particular instruction, but does it really create a closed API? Surely apple will release libraries that make use of it internally with appropriate compatibility guarantees. Is it inherently wrong for a hardware vendor to make a high-level C api the interface?

Support for different OSes might be interesting given that the C libraries mentioned seem to be Apple OSes only. Then the issue of having hidden instructions for high performance computation when CPU vendors have a history of bad performance/security tradeoffs. Other than that some languages have a bad time interacting with C or a high overhead when calling C functions.

Re: Undocumented arm64 ISA extension present on the Apple M1

#165

Post by Ericson2314 »

_-___________-_ wrote: post #152
vbezhenar wrote: post #148

Earlier quoted context omitted.

What’s wrong with releasing documentation clearly stating that those instructions are not guaranteed to be present in the future? Apple does not hesitate to break compatibility anyway.

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.

This isn't the Windows ecosystem. Apple breaks everything all the time, and there's hardly a squeal. There is no company less afraid of "de facto stable" than Apple.

Re: Undocumented arm64 ISA extension present on the Apple M1

#166

Post by Ericson2314 »

colejohnson66 wrote: post #163
vbezhenar wrote: post #148

Earlier quoted context omitted.

What’s wrong with releasing documentation clearly stating that those instructions are not guaranteed to be present in the future? Apple does not hesitate to break compatibility anyway.

Exhibit A is Windows. Microsoft publishing APIs and saying not to rely on them doesn’t work. Sure, Apple doesn’t care about backwards compatibility like Microsoft, but Apple will be blamed for breaking changes; They already are every time they change things.

Since when does Apple care if they are blamed?

Re: Undocumented arm64 ISA extension present on the Apple M1

#167

Post by noizejoy »

userbinator wrote: post #112
Someone wrote: post #34

Earlier quoted context omitted.

I think it’s more a sign of the times than Apple being Apple that they don’t tell you what hardware you buy when you buy one of their systems or how it is connected. Television manuals used to contain hardware schematics, car manuals used to be way more detailed, etc. Apple also had detailed info on their hardware. The Apple II reference manual had schematics, mapped it to the PCB, described what each part did, descr…

The keyword being had , but Apple has always been on the more closed side --- Inside Macintosh was far more pretty but overall less informative than the corresponding IBM PC Technical Reference books.

And Apple is still making Macs, while IBM gave up making PCs quite a while ago. Who would have predicted that in the mid 90s?

Re: Undocumented arm64 ISA extension present on the Apple M1

#168

Post by [deleted] »

my123 wrote: post #153
lumost wrote: post #142

Earlier quoted context omitted.

it limits Assembler access and tools written against that particular instruction, but does it really create a closed API? Surely apple will release libraries that make use of it internally with appropriate compatibility guarantees. Is it inherently wrong for a hardware vendor to make a high-level C api the interface?

Accelerate.framework uses them today, and provides a public interface.

[deleted]

Re: Undocumented arm64 ISA extension present on the Apple M1

#169

Post by GeekyBear »

lukeh wrote: post #136

I see undocumented instruction extensions as a special case of private API: it buys Apple the freedom to change the underlying implementation in the future. As long as done in a manner that is not anticompetitive, I don't see the problem.

The point of the Accelerate.framework is that it is the API and also abstracts away hardware differences between the processors of macOS, iOS, tvOS, and watchOS devices.

>Accelerate provides high-performance, energy-efficient computation on the CPU by leveraging its vector-processing capability. The following Accelerate libraries abstract that capability so that code written for them executes appropriate instructions for the processor available at runtime

https://developer.apple.com/documentation/accelerate

Re: Undocumented arm64 ISA extension present on the Apple M1

#170

Post by phone8675309 »

_-___________-_ wrote: post #152
vbezhenar wrote: post #148

Earlier quoted context omitted.

What’s wrong with releasing documentation clearly stating that those instructions are not guaranteed to be present in the future? Apple does not hesitate to break compatibility anyway.

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.

Post reply on HN