day23: Day 23: Coprocessor Conflagration

Description Usage Arguments Details Examples

Description

Coprocessor Conflagration

Usage

1

Arguments

commands

a character vector of commands to evaluate

Details

Part One

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:

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?

Part Two

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?

Examples

1
2
3
4
5
6
7
8
m <- create_coprocessor(c("set a 0", "sub a -2", "mul a 2", "mul a 3"))
m$.eval_next()
# Different levels of debugging info
m$.eval_next(1)
m$.eval_next(2)
m$.eval_next(2)
m$.counts
m$a

tjmahr/adventofcode17 documentation built on May 30, 2019, 2:29 p.m.