| Part 1 | Part 2 |
|---|---|
4225 |
905 |
You decide to head directly to the CPU and fix the printer from there. As you get close, you find an experimental coprocessor doing so much work that the local programs are afraid it will halt and catch fire. This would cause serious issues for the rest of the computer, so you head in and see what you can do.
The code it's running seems to be a variant of the kind you saw recently on that tablet. The general functionality seems very similar, but some of the instructions are different:
set X Ysets registerXto the value ofY.sub X Ydecreases registerXby the value ofY.mul X Ysets registerXto the result of multiplying the value contained in registerXby the value ofY.jnz X Yjumps with an offset of the value ofY, but only if the value ofXis not zero. (An offset of2skips the next instruction, an offset of-1jumps to the previous instruction, and so on.)
Only the instructions listed above are used. The eight registers here, named a through h, all start at 0.
The coprocessor is currently set to some kind of debug mode, which allows for testing, but prevents it from doing any meaningful work.
If you run the program (your puzzle input), how many times is the mul instruction invoked?
Now, it's time to fix the problem.
The debug mode switch is wired directly to register a. You flip the switch, which makes register a now start at 1 when the program is executed.
Immediately, the coprocessor begins to overheat. Whoever wrote this program obviously didn't choose a very efficient implementation. You'll need to optimize the program if it has any hope of completing before Santa needs that printer working.
The coprocessor's ultimate goal is to determine the final value left in register h once the program completes. Technically, if it had that... it wouldn't even need to run the program.
After setting register a to 1, if the program were to run to completion, what value would be left in register h?