Live data from Hacker News

Undocumented arm64 ISA extension present on the Apple M1

gist.github.com

31–40 of 202 posts

Re: Undocumented arm64 ISA extension present on the Apple M1

#31
post #18

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…

They didn't have to open the platform for other software (OS) at all. Let's be happy with what we got.

> Let's be happy with what we got.

Ouch. It's exactly this mentality that enables malicious actors - "it could be worse". It could always be worse, but that doesn't make it sufficient justification.

Functional equivalent: "It could always be even more anticompetitive. Let's be happy with what we got."

Re: Undocumented arm64 ISA extension present on the Apple M1

#32

Earlier quoted context omitted.

The implication I assume that there would be pushback on Microsoft for doing the same would be because of the possibility of nefarious undocumented changes. What possibly nefarious things could an undocumented ISA extension do?

Presumably the next iteration of the processor can remove them and use the opcodes for something else. Apple recompiles their system library, hence is unaffected. You can't do the same so peak M1 performance is unavailable for you.

Could those opcodes then be used for anything nefarious, or would it just restrict third parties from fully utilizing the processor?

Re: Undocumented arm64 ISA extension present on the Apple M1

#33
post #22
post #7

Earlier quoted context omitted.

In the bigger picture Apple aren't really documenting anything for their new toys, which is not the end of the world but is a huge step back for openness. There is - as far as I can see - no long-form documentation for M1 other than patents. I already refuse to own apple products so I don't really have any skin in the game, but consider that if microsoft were like this the blind eye would not be turned - buy our new…

As someone who was actually thinking about getting the M1 based on the great performance and battery life, but without any actual use for it, I can see what you mean. But the lack of openness is enough to stop those ideas, a new Surface laptop or next generation AMD mobile is much more useful. I just hope that a battery life breakthrough is on the horizon from AMD or Intel.

>I just hope that a battery life breakthrough is on the horizon from AMD or Intel.

Intel has their Lakefield chips which use the same big.LITTLE configuration but their first large release chips will be Alder Lake next year.

My concern is less with Intel and AMD's ability to implement the cores as much as Microsoft's ability to implement a scheduler. They never came to grips with the weirdness of AMD's Bulldozer architecture.

Re: Undocumented arm64 ISA extension present on the Apple M1

#34
post #7

Earlier quoted context omitted.

In the bigger picture Apple aren't really documenting anything for their new toys, which is not the end of the world but is a huge step back for openness. There is - as far as I can see - no long-form documentation for M1 other than patents. I already refuse to own apple products so I don't really have any skin in the game, but consider that if microsoft were like this the blind eye would not be turned - buy our new…

>In the bigger picture Apple aren't really documenting anything for their new toys, This should not come as a surprise, it has always been Apple's default stance. Apple has been, is, and will very likely always be a closed ecosystem. They might sometimes appear or pretend to be open, but it's essentially good PR/marketing (e.g. stash Unix underneath a closed-source stack, call yourself open source and proceed to lure…

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, described 6502 assembly and had an assembly listing of the monitor ROM. The only thing missing to build a copy, I think, was an assembly listing of the Basic interpreter.

The phone book edition of Inside Macintosh also had info on the hardware, but a lot less of it.

Re: Undocumented arm64 ISA extension present on the Apple M1

#35
post #7
post #2

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

In the bigger picture Apple aren't really documenting anything for their new toys, which is not the end of the world but is a huge step back for openness. There is - as far as I can see - no long-form documentation for M1 other than patents. I already refuse to own apple products so I don't really have any skin in the game, but consider that if microsoft were like this the blind eye would not be turned - buy our new…

> Apple aren't really documenting anything for their new toys

This seems an odd strategy for an accelerator. How are they expecting that people will use these new instructions? Only through Apple-supplied closed source compilers and libraries? (This is not meant to indicate you're wrong, only I'm confused about Apple's strategy)

Re: Undocumented arm64 ISA extension present on the Apple M1

#36

Earlier quoted context omitted.

Presumably the next iteration of the processor can remove them and use the opcodes for something else. Apple recompiles their system library, hence is unaffected. You can't do the same so peak M1 performance is unavailable for you.

Could those opcodes then be used for anything nefarious, or would it just restrict third parties from fully utilizing the processor?

If you think Apple wants to do something nefarious to users of their hardware, don’t buy or use it.

If they can’t be trusted, they don’t need to add opcodes.

Re: Undocumented arm64 ISA extension present on the Apple M1

#37
post #7

Earlier quoted context omitted.

In the bigger picture Apple aren't really documenting anything for their new toys, which is not the end of the world but is a huge step back for openness. There is - as far as I can see - no long-form documentation for M1 other than patents. I already refuse to own apple products so I don't really have any skin in the game, but consider that if microsoft were like this the blind eye would not be turned - buy our new…

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…

AMX was first announced for the A13 [1], so it's been in the wild for over a year now.

1: https://www.anandtech.com/show/14859/apple-announces-new-iph...

Re: Undocumented arm64 ISA extension present on the Apple M1

#38
post #35
post #7

Earlier quoted context omitted.

In the bigger picture Apple aren't really documenting anything for their new toys, which is not the end of the world but is a huge step back for openness. There is - as far as I can see - no long-form documentation for M1 other than patents. I already refuse to own apple products so I don't really have any skin in the game, but consider that if microsoft were like this the blind eye would not be turned - buy our new…

> Apple aren't really documenting anything for their new toys This seems an odd strategy for an accelerator. How are they expecting that people will use these new instructions? Only through Apple-supplied closed source compilers and libraries? (This is not meant to indicate you're wrong, only I'm confused about Apple's strategy)

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

Re: Undocumented arm64 ISA extension present on the Apple M1

#39
post #7

Earlier quoted context omitted.

In the bigger picture Apple aren't really documenting anything for their new toys, which is not the end of the world but is a huge step back for openness. There is - as far as I can see - no long-form documentation for M1 other than patents. I already refuse to own apple products so I don't really have any skin in the game, but consider that if microsoft were like this the blind eye would not be turned - buy our new…

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…

Apple must support base LLVM functionality because it is the core of their extend-embrace-extinguish strategy. This says nothing that they will extend that offer to their undocumented secret sauce, as you imply.

Re: Undocumented arm64 ISA extension present on the Apple M1

#40
post #18

Earlier quoted context omitted.

They didn't have to open the platform for other software (OS) at all. Let's be happy with what we got.

> Let's be happy with what we got. Ouch. It's exactly this mentality that enables malicious actors - "it could be worse". It could always be worse, but that doesn't make it sufficient justification. Functional equivalent: "It could always be even more anticompetitive. Let's be happy with what we got."

Eh, what? What malicious actors? What sufficient justification, and justification of what and to whom? What could be worse? What could be more anticompetitive, and competing with what exactly? I said nothing like this, your "equivalents" are from an entirely different world.

I said we should be happy Apple decided to open their platform - because they didn't have to, at all. It's entirely their right to not open anything, not write any documentation, or not even allow 3rd party software at all. If you don't like it, don't buy their overpriced premium products - it's not for you. I wouldn't want my own company to be forced to do/not do stuff, so of course I don't wish that upon Apple. There are enough entirely open computing platforms that are VERY cheap to obtain and easy to use, perhaps that would be a better choice for you.

Post reply on HN