Code Optimization: Interrupt when a value reaches 0
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:
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:

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.

You will loose an extra cycle in the pin synchronizer.

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

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

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...

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 return
(4 cycles) to the ISR. You could avoid this indirection by defining
the ISR yourself instead of relying on attachInterrupt().

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.

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:
if (--amp == 0) amp = 10;

would be translated by the compiler into something like this:
   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.