> They ditched that once Rosetta support on ARM Macs was good enough to run x86_64 VMs, as apparently all they cared about was supporting Docker on Macs...
Was a research project gone out of hand, arm64 macOS wasn't on the radar and the IoT product it was released for didn't succeed.
> I think it is essentially "complete drawbridge", too. I haven't played around with it in a while, but from memory, you can coerce it to run arbitrary Windows executables, basically anything without graphics (which are missing from the PAL they ship).
sbtrans (for arm64) was static binary translation only. No JIT fallback whatsoever.
> It's quite impressive, though also necessary if you think about it. SQL Server requires the legacy dot net stack,
The arm64 sbtrans-based version had that gone too, and it didn't have a nice engineering path towards supporting those. It'll come back later though I'm pretty sure, with using a more native arm64 version (or arm64EC which exists nowadays)
> AND it also ships with a full copy of the msvc compiler/linker! Not sure if that's ever used by the Linux port, but it is installed. MSSQL kind of exercises every inch of the Windows API surface.
Yes that's used for dynamic query optimisation. It was disabled in Azure SQL Edge for arm64 as that was a JIT-less translated version.
Is it actually redacted, or just a leftover stub from a feature implemented in silicon instead of software? Isn't the x86 memory order compatibility done at hardware level?
After Power9, IBM became uncompetitive multi-core performance against mainstream server CPUs - both x86 and Arm. They didn't keep up with the rise in core counts.
And the single thread side isn't that good either, but SMT8 is a quite nice software licensing trick
Secure Boot is still supported in that configuration, but with PK/db/dbx being part of the firmware configuration and updating them requiring a UEFI capsule update.
SME2 is restricted in scope to matrix multiply workloads and isn't really designed for anything else.
The point of streaming SVE is to have a way to pre/post process data on the way in or out of a matrix multiply.
A list that I have around of chips which support various levels of SVE:
For SVE(1) deployment, chips that have it:
- Fujitsu A64fx
- AWS Graviton3
SVE2:
- Snapdragon X2, 8/8 Elite Gen 5 and later
- MediaTek Dimensity 9000 and later
- NVIDIA Tegra Thor and later, NVIDIA "N1" or later (GB10 is an "N1x" SKU)
- Samsung Exynos 2200 or later
- AWS Graviton4, Microsoft Cobalt 100, Google Axion (and newer chips)
- CIX P1
SME(1) instead of SME2:
- Snapdragon X2, 8/8 Elite Gen 5
SME2:
- Apple M4, A18 and later
- Samsung Exynos 2600
- MediaTek Dimensity 9500
Note that the Snapdragon 8/8 Elite Gen 5 and X2 support sve2 but not svebitperm.
Was a research project gone out of hand, arm64 macOS wasn't on the radar and the IoT product it was released for didn't succeed.
> I think it is essentially "complete drawbridge", too. I haven't played around with it in a while, but from memory, you can coerce it to run arbitrary Windows executables, basically anything without graphics (which are missing from the PAL they ship).
sbtrans (for arm64) was static binary translation only. No JIT fallback whatsoever.
> It's quite impressive, though also necessary if you think about it. SQL Server requires the legacy dot net stack,
The arm64 sbtrans-based version had that gone too, and it didn't have a nice engineering path towards supporting those. It'll come back later though I'm pretty sure, with using a more native arm64 version (or arm64EC which exists nowadays)
> AND it also ships with a full copy of the msvc compiler/linker! Not sure if that's ever used by the Linux port, but it is installed. MSSQL kind of exercises every inch of the Windows API surface.
Yes that's used for dynamic query optimisation. It was disabled in Azure SQL Edge for arm64 as that was a JIT-less translated version.
reply