[LANGUAGE: dc (GNU v1.4.1)]

Just part 1. This is something you probably don't want to run. Dc does not have an XOR, I quickly implemented a 24-bit one (brain foggy day so its not the most efficient), and it took 90 minutes to run (on 15-year-old hardware, you'll probably have better).

dc -e'[0d[3R4R2~3R2~3R-d*4Rd2r^3R*5R+r1+d24>L]dsLx3R4R++s,]s^?[2000[rd64*l^xd32/l^xd2048*l^xr1-d0<I]dsIx+lp+sp?z0<M]dsMxlpp' <input

Code: https://pastebin.com/pJz5nz2H

I was able to test it in much less time though, because many years ago, I embedded Perl in an older version of dc (v1.3) and still have that executable around from when I brought that out for AoC a few years ago. It required some maintenance then (the details for embedding Perl had changed a bit) to get it to compile, but it seems to work fine. I really should embed Perl properly in a newer version, because its convenient and cool.

Anyways, that allowed me to replace the dc XOR function with:

  { #2!# (int($_[0]) ^ int($_[1])) & 0xffffff } s^

(The part in #s at the start tells it to only look at the top two elements, and pop (!) them... so this pops the top 2, and pushes the 24-bit XOR of those.)

So, I suppose this means that I have used a "language" (well, dialect) that I created this year. So, [LANGUAGE: edc] I guess (extended dc... that's what I called it). This allows the thing to complete in 90s instead of 90m. So that's the lower bound on what can be gained by improving the XOR implementation.