3 ms·

While some of the specifics are obviously x86 specific, I'm not sure that the underlying issues here are. From undocumented instructions, to lack of documentat

While some of the specifics are obviously x86 specific, I'm not sure that the underlying issues here are. From undocumented instructions, to lack of documentation about speculation barriers most of the root issues you see here are equally applicable to the cores in an M1.

als0 6y ago
> to lack of documentation about speculation barriers Can you elaborate on this? I was having a look at the M1 instructions here [1] and it seems that they implement at least one of the barriers, CSDB, which is actually documented by ARM[2]. [1] https://dougallj.github.io/applecpu/firestorm-int.html https://dougallj.github.io/applecpu/firestorm-int.html [2] https://developer.arm.com/documentation/ddi0596/2020-12/Base-Instructions/CSDB--Consumption-of-Speculative-Data-Barrier- https://developer.arm.com/documentation/ddi0596/2020-12/Base...
- monocasa 6y ago
  There's explicit speculation barriers that they document, but they don't tell you what _other_ instructions are speculation barriers simply due to microarchitectural compromises like what you're seeing in this article.
  - als0 6y ago
    OK thanks for clarifying. If there are explicit instructions for blocking speculation then why are you concerned about implicit barriers?
    - monocasa 6y ago
      I'm not. My point is that this article was being unfairly interpreted by the parent as some black mark against x86. There's plenty to hold against it, but not really anything that's documented here. I probably should have made that clearer.
    - phkahler 6y ago
      Seems like implicit undocumented barriers could be used in critical code to provide unfair performance advantage. Maybe. Might be a bit of a stretch.
mhh__ 6y ago
I'm kind of curious whether Apple aren't documenting M1 because they can't be bothered, can't (not organized enough yet), or because it's their toy not ours.
- monocasa 6y ago
  D) Scared that disclosing microarchitectural details will open them up to more patent fights that they have to pay off without a lot of benefit to endusers or developers. E) All of the above
  - marcan_42 6y ago
    E) Because they are doing things nobody else is allowed to (extending the ARMv8-A instruction set outside of the implementation-defined register mechanism, and blatantly breaking ARM architectural requirements like hard-coding VHE mode to on), and ARM lawyers are on the edge of their seats. No, really, Apple are going out of their way not to document certain details about the M1, and this is almost certainly the reason. ARM are scared to death of fragmentation, Apple somehow managed to get away with doing it anyway, and ARM do not want anyone else to get any ideas.
    - monocasa 6y ago
      If Apple cared what ARM thought, they would have finished implementing the spec. AArch64 is as much Apple's as it is ARM's and I doubt they're scared. They have a do wtf you want license and ultimately don't really care if the rest of ARM withers and dies.
      - marcan_42 6y ago
        There is no such "do wtf you want" license. The ARM architectural license allows licensees (like Apple, Cavium, Samsung, and others) to implement CPUs that comply with the architecture. Some things are off-limits, like custom instructions. Apple broke those rules. They probably got away with doing that as a "special exception" under the understanding that they were doing so for "embedded" use cases, i.e. iOS devices that will only ever run iOS, but now that their designs are in an open platform (M1), things have changed, and ARM is not happy.

als0 6y ago

> to lack of documentation about speculation barriers Can you elaborate on this? I was having a look at the M1 instructions here [1] and it seems that they implement at least one of the barriers, CSDB, which is actually documented by ARM[2]. [1] https://dougallj.github.io/applecpu/firestorm-int.html https://dougallj.github.io/applecpu/firestorm-int.html [2] https://developer.arm.com/documentation/ddi0596/2020-12/Base-Instructions/CSDB--Consumption-of-Speculative-Data-Barrier- https://developer.arm.com/documentation/ddi0596/2020-12/Base...

monocasa 6y ago
There's explicit speculation barriers that they document, but they don't tell you what _other_ instructions are speculation barriers simply due to microarchitectural compromises like what you're seeing in this article.
- als0 6y ago
  OK thanks for clarifying. If there are explicit instructions for blocking speculation then why are you concerned about implicit barriers?
  - monocasa 6y ago
    I'm not. My point is that this article was being unfairly interpreted by the parent as some black mark against x86. There's plenty to hold against it, but not really anything that's documented here. I probably should have made that clearer.
  - phkahler 6y ago
    Seems like implicit undocumented barriers could be used in critical code to provide unfair performance advantage. Maybe. Might be a bit of a stretch.

mhh__ 6y ago

I'm kind of curious whether Apple aren't documenting M1 because they can't be bothered, can't (not organized enough yet), or because it's their toy not ours.

monocasa 6y ago
D) Scared that disclosing microarchitectural details will open them up to more patent fights that they have to pay off without a lot of benefit to endusers or developers. E) All of the above
- marcan_42 6y ago
  E) Because they are doing things nobody else is allowed to (extending the ARMv8-A instruction set outside of the implementation-defined register mechanism, and blatantly breaking ARM architectural requirements like hard-coding VHE mode to on), and ARM lawyers are on the edge of their seats. No, really, Apple are going out of their way not to document certain details about the M1, and this is almost certainly the reason. ARM are scared to death of fragmentation, Apple somehow managed to get away with doing it anyway, and ARM do not want anyone else to get any ideas.
  - monocasa 6y ago
    If Apple cared what ARM thought, they would have finished implementing the spec. AArch64 is as much Apple's as it is ARM's and I doubt they're scared. They have a do wtf you want license and ultimately don't really care if the rest of ARM withers and dies.
    - marcan_42 6y ago
      There is no such "do wtf you want" license. The ARM architectural license allows licensees (like Apple, Cavium, Samsung, and others) to implement CPUs that comply with the architecture. Some things are off-limits, like custom instructions. Apple broke those rules. They probably got away with doing that as a "special exception" under the understanding that they were doing so for "embedded" use cases, i.e. iOS devices that will only ever run iOS, but now that their designs are in an open platform (M1), things have changed, and ARM is not happy.