Undocumented arm64 ISA extension present on the Apple M1 • Hacker News Board

Re: Undocumented arm64 ISA extension present on the Apple M1

#91

Post by fsflover » Mon, Dec 28, 2020, 9:35 PM UTC

user-the-name wrote: post #48

tenebrisalietum wrote: post #17

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. It's similar to how Microsoft doesn't make all APIs on Windows public and uses non-public ones for various reasons--except this is in hardware. It's possible the undocumented ISA is used to speed up x86 emu…

> 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.

> Why would they?

I don't know why, but they are already doing it with browsers on iOS: https://docs.house.gov/meetings/JU/JU05/20190716/109793/HHRG...

Are there any WebKit functions that Apple allows Safari to use but that competing browsers are not permitted to use?

WebRTC for videoconferencing, Intelligent Tracking Protection, Fullscreen API

Re: Undocumented arm64 ISA extension present on the Apple M1

#92

Post by keyle » Mon, Dec 28, 2020, 9:36 PM UTC

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

No it wasn't always this bad. The speed at which Swift has changed has left the documentation behind. I've complained about this numerous times.

Simply put, if you want useful doco don't look at the latest version of the language. They literally stripped the useful notes and examples and it's now a straight API print out.

If you use stackoverflow (sarcasm) be prepared to constantly be using older versions of swift and translating them to the latest. Feel free to submit updates to them.

So it does help to understand what changed in the language versions. I think anything past Swift 3 is similar to today. Xcode does help a little telling you what you pasted makes no sense to a degree.

It's a very sad state of affairs I'm afraid.

Re: Undocumented arm64 ISA extension present on the Apple M1

#93

Post by rgovostes » Mon, Dec 28, 2020, 9:37 PM UTC

monocasa wrote: post #71

rgovostes wrote: post #59

Earlier quoted context omitted.

Don't be absurd. LLVM was a research project until Apple hired Chris Lattner and poured money into it to make a viable alternative to GCC. They've been among the project's top contributors (financially and in terms of code) for 15 years. That's quite the long con. Apple creates plenty of proprietary technologies but I can't think of a time they've been credibly accused of crushing an open technology that already exis…

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.

Re: Undocumented arm64 ISA extension present on the Apple M1

#94

Post by whatshisface » Mon, Dec 28, 2020, 9:37 PM UTC

_underfl0w_ wrote: post #30

whatshisface wrote: post #21

Earlier quoted context omitted.

Of course, and Apple's ISA is targeted towards the People Who Buy Macs industry. By not making it available to datacenters, they are supporting other CPU vendors in the race to catch up. It will help AMD a lot in their bid to catch up that all investors can see that Apple won't be competing with them.

> By not making it available to datacenters, they are supporting other CPU vendors in the race to catch up. This is by far the most charitable characterization of this monetization scheme I've seen so far. Some would argue this is actually in place to ensure that purchases go directly through Apple each time (i.e. a one-to-one of customers to hardware purchases), rather than through a cloud provider who may purchase…

"Apple is extracting value at monopoly-pricing levels" == "Apple is leaving tasty treats on the table to lure competitors." They're the same statement but phrased in different ways. Any price above the equilibrium lures competitors - that's how markets avoid monopoly pricing, in the absence of external factors that protect the monopoly.

Re: Undocumented arm64 ISA extension present on the Apple M1

#95

Post by mhh__ » Mon, Dec 28, 2020, 9:38 PM UTC

ithkuil wrote: post #63

Teongot wrote: post #26

Earlier quoted context omitted.

There's a tidy mathematical progression in Apple CPU architectures. 6502 (Apple 1,2,3): 1976 68k (Mac): 1984 (+8 years) PPC: 1994 (+10 years) x86: 2006 (+12 years) ARM: 2020 (+14 years) If the trend continues, we will see Apple's next architecture in 2036.

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.

Re: Undocumented arm64 ISA extension present on the Apple M1

#96

Post by whatshisface » Mon, Dec 28, 2020, 9:40 PM UTC

mhh__ wrote: post #81

ardy42 wrote: post #55

Earlier quoted context omitted.

> The Russian CPU isn't surviving in a market How so? It's actually not that different from Apple Silicon when you think about it. Apple Silicon: you only get it when you buy an iPhone, iPad, ARM Mac, etc. in the Smartphone or PC market; and it enables features that make those devices competitive. Russian Elbrus: you only get it when you buy some Russian military hardware in the defense market; and it enables feature…

Because guaranteed sales from the government is clearly not the same as having to compete with Intel and AMD

M1 does not compete with Intel or AMD. (M1)(Apple)(OSX) competes with (Intel | AMD)(Choose any OEM)(Windows | Linux). All sales of the M1 chip are "guaranteed sales," to Apple itself, building macs.

Re: Undocumented arm64 ISA extension present on the Apple M1

#97

Post by rgovostes » Mon, Dec 28, 2020, 9:41 PM UTC

dayjobpork wrote: post #77

rgovostes wrote: post #61

Earlier quoted context omitted.

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.

You think it is bad that a company provides good documentation on how their product works and how to use it?

This is not an accurate characterization of what I wrote whatsoever. Please don't misquote people in order to start flamewars.

Re: Undocumented arm64 ISA extension present on the Apple M1

#98

Post by TheNewAndy » Mon, Dec 28, 2020, 9:48 PM UTC

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

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 price of the laptop to repair, so I decided to do another rewrite - this time, using my linux laptop.

The experience of writing it in plain documented C, and using libSDL2 for most of the IO was far superior. Writing my own physics engine instead of using the SpriteKit one made the actual gameplay better (because it meant I could easily fudge physics a bit to make it more fun).

Only at the very end of the project did I then go through the painful process of making it happy with xcode, happy to build for iOS, and then finally happy with the Apple review process (including hacking my SDL build to remove bluetooth peripheral support so I didn't need to request unwanted permissions).

I now have an M1 Macbook Air, and I've briefly looked again at doing things the "apple way" (e.g. swiftui) and I'm coming to a similar conclusion.

Re: Undocumented arm64 ISA extension present on the Apple M1

#99

Post by comex » Mon, Dec 28, 2020, 9:55 PM UTC

rwmj wrote: post #46

ac29 wrote: post #38

Earlier quoted context omitted.

> How are they expecting that people will use these new instructions? Only through Apple-supplied closed source compilers and libraries? This sounds right. Forcing people to use Apple supplied and supported libraries allows Apple to make major changes in hardware without breaking compatibility (there are always edge cases, though).

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).

Accelerate.framework is a shared library distributed with the OS. Like most other system libraries, it’s not available as a static library, and though you could theoretically ship a copy of it in an app bundle, you’re not supposed to. Instead the ABI is kept backwards-compatible.

There’s no publicly available compiler, proprietary or not, that produces binaries that use the instructions.

Re: Undocumented arm64 ISA extension present on the Apple M1

#100

Post by mlazos » Mon, Dec 28, 2020, 10:05 PM UTC

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!