3 ms·
> How are they expecting that people will use these new instructions? Only through Apple-supplied closed source compilers and libraries? This sounds right. For
by ac29 6y ago
> 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).
- rwmj 6y agoIf 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).
- Someone 6y agoThe public compiler wouldn’t generate them, or only generate them when compiling with a special flag.
- egsmi 6y agoIn 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/ https://lowlevelbits.org/bitcode-demystified/
- saagarjha 6y agoBitcode wouldn't really help too much here.
- realusername 6y agoApple does not care that much about backward compatibility so having two incompatible binaries with the same architecture wouldn't shock me that much.
- comex 6y agoAccelerate.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.