As a fun challenge for this year's advent of code, I decided to try solving each day's challenge in assembly for a different architecture, and obtaining that day's solution by running the code on a physical processor of that architecture. For each day that I solve, I will be uploading my code and details of what device it was run on here. I attempted this challenge last year but quickly fell behind and stopped after day 11. This time, my goal is to finish all 25 days by the end of the year. The specific rules I will be following this year are detailed as follows and are largely similar to last year with a few extra stipulations:

• For purposes of the challenge, "different architecture" is loosely defined as "different first item in an LLVM target triple." This means I get to count armv4, v5, etc as all different architectures, which should make this significantly more possible for me. This can still get a little fuzzy in some cases of course, so I'm deciding most things on a case-by-case basis.
• The physical processor used must actually match the architecutre used, so writing a solution in "armv4" assembly then running it in the aarch32 mode of an armv8 CPU would not be allowed. This is to encourage finding a wide variety of hardware to use, rather than 5 different modern smartphones.
• Calling into higher level or library code is only allowed when it is necessary to communicate with the outside world, like to print some output or read the input file (as raw text) from somewhere. I have allowed myself to make use of the number-to-text functionality of printf-like library functions where available, because writing 25 itoa implementations isn't very exciting.
• Emulators and similar may be used to debug the code on the AoC sample input or other manufactured test cases, but attempts at getting the solution with the real puzzle input may only be made on the target hardware.
• As a new rule this year, hardcoding the puzzle input data into the binary at compile time is not allowed. That is, the solution (although not necessarily the assembly part of it, as that would sometimes be impossible) must retrive the input from stdin, from a file that could be changed at runtime, over the network from the AoC site itself, or something else along those lines. This isn't a large change and many of my previous solutions already followed this rule, but I feel it will make some opporitunities for a little more hardware-specific creativity in some cases.

I invite everyone reading this to try this challenge or a variation on it for themselves, and if you do, please let me know! I'd love to see some other creative hardware choices. In any case, good luck and have fun with AoC this year!