Request for ARM Assembly(64bit) Track

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:

  1. If a student has an ARM processor to use locally, it will most likely be 64bit(Mac, PC, RaspberryPI) at this point.
  2. I think it makes sense to align with the x86_64 bit track.

Let me know what you think.

ARM 32 bit discussion: Request for ARM Assembly (32 bit) Track - #17 by ChrisBoerner

OK great. Let’s create a new repo for this and get you set up on (rather than convert the existing one).

@ErikSchierboom Could you do the honours of this and the test runner pls?

And then hopefully we can use the x86_64 as a quick accelerator for this!

Would any other senior maintainers like to help out on this (and get write-permissions)?

2 Likes

What would the official name and slug be?

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.

1 Like

I would agree with @BNAndras

FWIW, the Linux kernel calls it arm64, and so does Debian. OTOH, Fedora seems to call it ARM AArch64, GCC calls it aarch64 and so does llvm (try clang -print-targets).

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.

3 Likes

I can contribute a handful of exercises.

Great! Once we have a repo ready, we can get started.

@kmarker1101 Apparently, there was an existing GitHub - exercism/arm64-assembly: Exercism exercises in Arm64 Assembly. repo, but it was archived. I’ve unarchived and you have a request to join the maintainers team.

I’ve also created the test runner repo: GitHub - exercism/arm64-assembly-test-runner

@keiraville do you want to join that team too?

Thanks Erik

Yes please add me.

Done! You’ve been added to the team.

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.

It didn’t work for me when I overhauled the D track’s CI, but hopefully I just missed a setting somewhere.

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.

1 Like

The macos-14 runner is publicly available (see About GitHub-hosted runners - GitHub Docs) and is an M1 image, so that should be 64 bit ARM, right?

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.

Maybe

Anyone have any other ideas?

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.