I would like to request this track. I would definitely be willing to get it up and going and serve as a maintainer. There is a ARM Assembly 32bit track that has been started, but it seems to be stale at this point. I would prefer 64 bit for two reasons:
If a student has an ARM processor to use locally, it will most likely be 64bit(Mac, PC, RaspberryPI) at this point.
I think it makes sense to align with the x86_64 bit track.
We used “ARM32 Assembly” with slug arm32-assembly for the 32-bit track so “ARM64 Assembly” with slug arm64-assembly seems logical here.
Edit - Wikipedia indicates it’s formally named AArch64 nowadays, but ARM64 appears to be a valid shorthand name. I think ARM64 might still be more recognizable to a layperson than AArch64. To me, the latter reads like it might be an Apple Silicon-specific thing.
According to google trends, “arm64” is 3-4 times more popular than “aarch64” over the past year.
So, I agree “Arm64 Assembly” with slug arm64-assembly makes sense, but it’s probably worth mentioning the name AArch64 prominently in the description, as people might also be familiar with that.
Note: official branding is “Arm” (sentence case) - used to be ARM uppercase, but it changed a few years ago.
Github does have arm64 machines available, but only for enterprise or team accounts currently. Do we happen to fall into one of those categories? I ask, because it would simplify things for the test runner.
There is a macOS M1 available to us, which would be arm64. The idea being if the underlying VM is arm64, that would keep us from having to run an emulator inside the docker container.
That is correct. Those should work just fine. I think the linux arm64 runners will be publicly available later this year. We can always switch then, if we want.
BTW, there are differences between linux arm64 and macOS arm64. My thought was that this track would target linux arm64. As we are using a macOS-14 runner, we would just run everything inside a linux container.
I have run into a snag. The macOS-14 runner is a M1 which does not support nested virtualization. In other words, we can’t run docker. M2 and M3 do, but are not available.
The only other option I can think of is to use a x86_64 runner and then try to run an emulator inside docker. I have not done this and not sure it’s possible.
That’s really unfortunate. I think the simplest solution would be to not run the docker-based tests, but the regular tests. Then we can use the Linux-based ARM runner that GitHub plans to introduce at the end of the year and switch back to the docker-based test.