Hacker News Reader

Comment by ac29 | Hacker News Reader

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

View on HN

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

The public compiler wouldn’t generate them, or only generate them when compiling with a special flag.

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.

Apple does not care that much about backward compatibility so having two incompatible binaries with the same architecture wouldn't shock me that much.

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.

Reply on news.ycombinator.com