You did not specify the kind of Arduino you are using but, based on
another recent question of yours, I will assume it is an AVR-based
Arduino.

You cannot have an interrupt automatically triggered by a variable
reaching zero. What you can do, instead, is trigger an interrupt by
software, by toggling a pin that is configured both as an output and as
an interrupt source:

```c++
const uint8_t int_pin = 2;  // pin used for interrupt

void setup() {
    digitalWrite(int_pin, LOW);
    pinMode(int_pin, OUTPUT);
    attachInterrupt(digitalPinToInterrupt(int_pin, reset, RISING));
}

static inline void trigger_interrupt() {
    digitalWrite(int_pin, HIGH);
    digitalWrite(int_pin, LOW);
}

// Within loop():
if (!amp) trigger_interrupt();
```

However, if you do that, you will discover that interrupts are slow.
**Awfully slow** compared with a simple `if` test:

1. `digitalWrite()` itself is awfully slow. This can be overcome by
   using direct port access, but that is still two cycles for toggling
   the pin in each direction.

2. You will loose an extra cycle in the pin synchronizer.

3. Once the IRQ is raised, the CPU needs four cycles to prepare itself
   for servicing it.

4. The interrupt vector is a `jmp` instruction, which takes 3 cycles.

5. The ISR then has to save every single register it is going to use,
   including the status register. That takes two cycles per register.
   And there are quite a lot of registers to save...

6. This ISR, which is provided by the Arduino core, will then look for
   the interrupt handler you provided with `attachInterrupt()`. This
   also involves checking that the pointer to the handler is not zero
   (the kind of test you seem to be worried about). It then has to
   `call` (4 cycles) your handler, which will have to `ret`urn
   (4 cycles) to the ISR. You could avoid this indirection by defining
   the ISR yourself instead of relying on `attachInterrupt()`.

7. Once the job is done, all the saved registers have to be restored
   (2 cycles times many register), and the `reti` instruction (4 cycles)
   is issued in order to restore control to the interrupted program.

8. Last but not least, since `amp` will be modified in interrupt
   context, you will have to qualify it as `volatile`. This keyword
   prevents the compiler to perform optimizations that are unsafe in
   this situation, and you will loose _a lot_ of time to these missed
   optimization opportunities.

In contrast, this line:

```c++
if (--amp == 0) amp = 10;
```

would be translated by the compiler into something like this:

```lisp
   dec  amp     ; --amp, as amp is likely already in a register
   brne 1f      ; if (amp != 0) skip the following
   ldi  amp, 10 ; amp = 10
1:
```

The whole sequence takes 3 cycles, irrespective of whether the `if`
condition was true or false. That is at least one order of magnitude
faster than the interrupt-based solution.