docs: fix x86->x64

1 files changed, 1 insertions, 1 deletions

diff --git a/README.md b/README.md
index e57f776..b9e1eed 100644
--- a/README.md
+++ b/README.md
@@ -1,5 +1,5 @@
 # aoc

-My [AoC](https://adventofcode.com) solutions, written in x86-64 assembly. There is absolutely no good reason to pick assembly for this. I could have gone with C, C++, Rust, or pretty much anything else, but where's the fun in that? I'm doing this because I was bored, needed a reason to procrastinate, and, in any case, I don't have that many excuses to write assembly these days anymore, so these let me stay up to spec. Since assembly is beyond annoying to deal with between machines, I provide a Dockerfile with all the tools you might need to build and run the solutions.

+My [AoC](https://adventofcode.com) solutions, written in x64 assembly. There is absolutely no good reason to pick assembly for this. I could have gone with C, C++, Rust, or pretty much anything else, but where's the fun in that? I'm doing this because I was bored, needed a reason to procrastinate, and, in any case, I don't have that many excuses to write assembly these days anymore, so these let me stay up to spec. Since assembly is beyond annoying to deal with between machines, I provide a Dockerfile with all the tools you might need to build and run the solutions.

 

 I don't particularly care about the AoC leaderboard. December is usually a pretty busy time for me, so I often don't have the time (or energy) to sit down and solve every puzzle on the day it comes out. As a result, some solutions may be uploaded days, weeks, or potentially much later than the actual puzzle release. That's intentional. I'm doing these primarily because I enjoy solving the problems and because they're a fun excuse to write increasingly questionable amounts of assembly. Getting a good leaderboard position isn't really the point for me. If a solution appears suspiciously late, that's probably why.