macOS Big Sur status report
first.last at gmail.com
Sun Sep 13 19:51:14 UTC 2020
I'd like to post here to get you in touch with the future support
of macOS Big Sur.
Future Mac comes with "Apple Silicon" CPU that are natively arm64.
On these system (out end of 2020), you can run both x86_64 and
As of today, a D program works unchanged under macOS Big Sur
(11.0). It is emulated. The new processors are really fast and
it's surprisingly painless.
So there is no real urgency for transitioning, apart from keeping
native performance. For maximum compatibility one would
distribute "fat binaries", a arm64 executable stitched to a
x86_64 executable with the "lipo" tool.
2. druntime support
The triple is: arm64-apple-macos and currently it needs tweaks to
A druntime built for macOS 11.0 doesn't exist yet but is in the
druntime needs to be a bit adapted for Big Sur. It's mostly C
symbols that used to have OSX-specific names; it requires
You can thankfully hack around the current lack of runtime with
LDC by linking with the druntime built for iOS.
See progress here:
I'm just unaware which druntime needs to be touched: the LDC one
3. DUB support
It appears nothing needs to be done since DUB supports triple in
the -a flag.
$ dub -a arm64-apple-macos
4. intel-intrinsics support
The idea is to keep the x86 semantics of intel-intrinsics and get
it to work on arm64, at a slight performance loss. The extent of
the impedence mismatch is unknown yet.
This is a similar idea to the "simde" library on Github.
For now the goal has been to get to the same semantics through
the generic intrinsic implementations, and to get back
For now the goal was to find a way to respect the rounding
ARM have no MXCSR, rounding mode and flush-to-zero mode are put
into the ARM's FPCSR control word instead.
As there is no new ARM instruction to round using the current
rounding mode (which is definately a good design), we dispatch
after reading that control word.
What is unsupported for now is:
- FP exceptions flags and FP exceptions masks
- most intrinsics should be really slow. It will need detailed
work to ensure the fastest implementation of each and every x86
Thanks for reading and consider donating to LDC!
More information about the Digitalmars-d