Request for ARM Assembly(64bit) Track

Exercism Support
41

In my list of steps, I forgot about macOS and enabling CI for arm64 Mac.

It might be less distracting for students if we tell the linker instead of the compiler.

As an experiment I tried the following:

Changed the symbol used in the example solution:

.text
.global actual_hello
actual_hello:
    ...

Created a linker script text file containing

PROVIDE(hello = actual_hello);

Changed the Makefile so the file name for the above linker script is passed to the linker:

LDFLAGS = my_linker_script

This passes. So perhaps we can use this sort of approach to alias _hello to hello

generators/generate has in prop the name of the function being called, so it could generate the linker script.

(Alternately, if we came up with a different arrangement where we made a tiny per-exercise change to the Makefile instead of introducing a new linker script file, we could generate the various Makefiles from a template.)

42

No thanks. I donā€™t write assembly and I donā€™t have bandwidth to take on additional work.

43

I can try to help out for sure. But thereā€™s no way I can put in the officially stated 4 h/week. So if you can live with less, feel free to sign me up.

1 Like
44

Just curious. Where do you see that? Iā€™m definitely not putting in 4 hours a week on the tracks I maintain!

45

Your list looks excellent. I guess you have the rights to merge the runner PR? If so, you can go ahead and merge that.

About native macOS support, I played with it a bit more and came across more differences that could be too problematic. Concretely, I looked at hello_world. Apple clangā€™s as doesnā€™t like .section .rodata. Putting just .data works. However, even then it doesnā€™t work:

āÆ as hello_world.s
hello_world.s:7:5: error: ADR/ADRP relocations must be GOT relative
    adrp x0, msg
    ^
hello_world.s:7:5: error: unknown AArch64 fixup kind!
    adrp x0, msg
    ^
hello_world.s:8:5: error: unknown AArch64 fixup kind!
    add x0, x0, :lo12:msg
    ^

Looks like loading addresses into registers is done differently on macOS. I was able to make it work at some point, but then it didnā€™t compile on Linux. Maybe there is a syntax that will work for both, but for sure there are things that will compile on macOS but will not work on Linux. It will be fairly tricky to make that work with the Linux test runner. So for now I would suggest we go with the original idea of only targeting Linux.

But I think we should just the makefiles to support native Linux on arm64. Then we could also add a paragraph to the installation instructions for macOS users: they would use a Linux VM (or Docker container) for their native architecture.

46

Took a while to find it again, itā€™s stated here: Maintainers | Exercism's Docs

47

That document is from 2021 and should probably be updated. It seems out-of-date in a few spots.

48

In case 4 h/wk are not expected, feel free to sign me up!

The PR is merged now. Can we change the active entry in config.json then to see the test runner in action?

Open items from my perspective:

  • Update makefiles to support native arm64 Linux and emulated. I have a draft for that locally and could open a PR. Thereā€™s actually not much to change, the compiler and assembler calls work in both versions. Only the qemu call needs to go for native arm64.
  • Update installation documentation: here, we should also differentiate between native arm64 and other platforms, because you donā€™t need qemu when using a native arm64 platform; also add a paragraph for macOS users. Iā€™ve played with Lima recently and itā€™s what I would recommend.

Anything I forgot?