This PR does the following:
- Designs a mechanism by which arm64 instructions can be encoded and
emitted
- Dispatch our higher-level instruction emitting calls to either x86 or
arm64 instructions depending on what the compiler is set to (defaults to
x86)
- Bare minimum scaffolding to get the arm64 instructions successfully
executing atleast on apple silicon
- Implement enough instructions to get the codetester test suite passing
on arm
libidn2 which is a potential part of libcurl seemingly slipped into the
latest release (0.2.25) and it was dynamically linked.
This causes issues:
```
dyld[95648]: Library not loaded: /usr/local/opt/libidn2/lib/libidn2.0.dylib
Referenced from: <9DA6EC1D-F99A-3233-8264-AAEA87F07743> /Users/tyler/Downloads/opengoal-macos-arm-v0.2.25/gk
Reason: tried: '/usr/local/opt/libidn2/lib/libidn2.0.dylib' (no such file), '/System/Volumes/Preboot/Cryptexes/OS/usr/local/opt/libidn2/lib/libidn2.0.dylib' (no such file), '/usr/local/opt/libidn2/lib/libidn2.0.dylib' (no such file)
zsh: abort ./g
```
My theory for why is that the underlying image changed (now has this
library) and so the cmake detected that and started building with it.
The simple fix is to just disable it, as we don't need it. If we do
eventually, I can figure out how to ensure it's properly compiled.
Create explicit x86_64 and ARM64 macOS build targets, so it's clear that
the CI is building x86_64 binaries (on both Intel and ARM64 build
machines). Also, use the `CMAKE_APPLE_SILICON_PROCESSOR` CMake variable
(which sets `CMAKE_SYSTEM_PROCESSOR`) so `BUILD_X86_ON_MACOS` is not
necessary.
And update the README.
I havn't tested it yet, but I can almost guarantee that atleast `goalc`
will not work in the slightest!
But the project is atleast fully compiling. My hope is to start
translating some AVX to NEON next / get `goalc` working...eventually.
Tyler Wilding