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

151–160 of 202 posts

Re: Undocumented arm64 ISA extension present on the Apple M1

#151

Post by segfaultbuserr »

pishpash wrote: post #126
simonh wrote: post #66

Earlier quoted context omitted.

From an Apple perspective openness is a feature, not a goal in itself. Youre worrying about this or that specific ARM instruction, but Apple doesn't even want you to care whether it's ARM, or Intel, Or PowerPC, or whatever. It's an Apple system, part of the MacOS ecosystem and supported by Apple dev tools and power user features. If that's not the world you are interested in, what are you even doing owning a Mac? App…

That's true, at some level of abstraction you stop caring practically about openness. That line has shifted, and it points to hardware being commoditized more than lock-in. Do you care who made your logic gates or if it's documented?

> Do you care who made your logic gates or if it's documented?

Generally no. But it's something that worth an attempt, no matter how clueless the attempt is, something positive may come out of it. Here's an attempt to implement a free and open source standard cell library using the 1-micron process from the 80s.

https://github.com/chipforge/StdCellLib

Re: Undocumented arm64 ISA extension present on the Apple M1

#152

Post by _-___________-_ »

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.

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.

Re: Undocumented arm64 ISA extension present on the Apple M1

#153

Post by my123 »

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?

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

Re: Undocumented arm64 ISA extension present on the Apple M1

#154

Post by ndesaulniers »

ChuckMcM wrote: post #105
lwhi wrote: post #2

I don't understand the significance of this. Could someone who does add some context?

Like Intel, Apple has chosen to add some instructions to the processor which accelerate certain operations (in this case matrix operations). Unlike Intel, Apple has not yet chosen to actually document the M1 architecture. This is where a vertically integrated company like Apple (or IBM back in the day) can leverage "inside knowledge" about their chips to achieve performance that is not readily comparable (or reproduc…

So Intel's IWMMXT extensions to ARM (StrongARM) ended up having conflicting encodings with VFP, IIUC, making them mutually exclusive. While that's fine for one or the other, it complicates one binary targeting both (ie. the Linux kernel).

Re: Undocumented arm64 ISA extension present on the Apple M1

#155

Post by calo_star »

mhh__ wrote: post #84
calo_star wrote: post #82

Earlier quoted context omitted.

This really isn't new. It looks like instead of treating the "Neural Engine" as an I/O device like the GPU, it's accessed as a coprocessor. It makes sense for them to only expose their functionalities through libraries as the underlying hardware implementation will go through changes in the future. After all, does, say, Nvidia, document their GPU's ISA?

Yes. Not as much as the average CPU but still documented: https://developer.nvidia.com/blog/nvidia-ampere-architecture...

Where is the native-to-hardware ISA?

Re: Undocumented arm64 ISA extension present on the Apple M1

#156

Post by gsnedders »

rodgerd wrote: post #150
ytch wrote: post #123

Earlier quoted context omitted.

Apple might use these instruction in CoreML/Accelerate Framework and not integrated to LLVM as the author said: > This is an undocumented arm64 ISA extension present on the Apple M1. These instructions have been reversed from Accelerate (vImage, libBLAS, libBNNS, libvDSP and libLAPACK all use them), So we still cannot understand all of them from LLVM source code.

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?

Re: Undocumented arm64 ISA extension present on the Apple M1

#157

Post by aseipp »

rgovostes wrote: post #61
mhh__ wrote: post #51

Earlier quoted context omitted.

My point about the docs isn't the day-to-day stuff, but the things that cannot be machine generated - to write a good compiler you need to know the details of how the CPU is put together underneath. Intel will give you 800 pages on how to optimize for their current ISA (AMD will give you 45, but still)

As I understand it, Intel will also sell you a compiler that can optimize better than GCC because they know internal microarchitecture details. To me, that seems like a more clear-cut by-design conflict of interest between chip designer and user than these undocumented instructions.

Clang and GCC regularly go toe-to-toe with or exceed ICC and have plenty of architectural cost models for modern systems, in part thanks to the extensive documentation and free tools from Intel themselves. ICC does have some gimmick features like GPU offload, and (last I saw) much better auto-vectorization. But as far as run of the mill code goes, you aren't going to get some magical double-digit performance uplift on average scalar code that can only be attained by ICC and/or Intel doing subterfuge.

Beyond that, making a claim of a conflict of interest requires more than just "It seems like these words fit and sound right, to me." Because "Microprocessor company writes well optimized code for their microprocessors and sells it" hardly seems like a conflict of interest at all in this case, it literally seems like a company selling a product that goes with their existing product. Absolutely everybody does this, including AMD, IBM, Nvidia, Apple, etc. It is not a "conflict of interest" for Intel to both design a microprocessor and also sell code that works well on it. What might be a conflict of interest is if they said "We have an obligation to release these specifications, but also we can make lots of money off them if if we keep them private despite that existing obligation, so we'll just keep them private." Which is a much stronger claim. (In fact even the infamous "cripple AMD" legal SNAFU over ICC wasn't a conflict of interest, it was brought as an antitrust suit, AFAIK.) It's not like Twilio has a "conflict of interest" when they implement new features in their product portfolio, build them on Twilio's servers, and integrate them with other Twilio products.

In general, Intel is ahead of almost every other vendor when it comes to publicly-available information regarding performance optimization (first and third party), by a landslide.

Re: Undocumented arm64 ISA extension present on the Apple M1

#158

Post by Q6T46nT668w6i3m »

londons_explore wrote: post #124
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!

Other vendors ML hardware is very much "A far away device over the PCI express bus which you give bunch of work to and later come back and see if its done". Looks like apple has decided to make it very tightly integrated into the CPU. It means while doing ML operations, the CPU core can't go off and do other useful work. It also forces all cores to require matching ML hardware (or have a lot of OS complexity as certa…

The ML device is pretty much just a MATMUL processor.

Re: Undocumented arm64 ISA extension present on the Apple M1

#159

Post by megablast »

supermatt wrote: post #79
rgovostes wrote: post #25

Earlier quoted context omitted.

On the other hand, Apple released their 64-bit ARM backend for LLVM[1] in 2014. They announced their intention do so almost immediately after the first ARM64 phone, but the process took several months because it had to be merged with a duplicate backend developed by others. I think it is likely that support for these instructions will be upstreamed to LLVM, and the teams involved in this monumental transition (which…

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,…

It’s always been bad, but it got worse when they did a major design change to their website.

Re: Undocumented arm64 ISA extension present on the Apple M1

#160

Post by megablast »

TheNewAndy wrote: post #98
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,…

Yes. I have recently released my first game in the app store. It is a simple game, and so this is probably the 3rd rewrite of it. The second rewrite was when I finally had an apple device, so I thought "I will do everything the apple way" - I used Swift and SpriteKit, and tried to do everything exactly how I thought the Apple people would like. I then dropped that laptop, and was told it would cost more than the pric…

You should use git.
Post reply on HN