@arjan: IRQs aren't really the best option for precise timing (depending on how precise 'precise' needs to be). The latency is all over the place, especially if IRQs get disabled for any reason, or multiple interrupts need processing at the same time. IRQs are essentially assuming that the hardware is buffering data or using handshaking, or the speed is low enough for latency to be unimportant. FIQs are better, if accessing the gpio pins has to be done in the background (they were designed for reading data out of a latch before it gets overwritten by new data). Still not too precise. You could tie some pins together and use (say) PWM to generate a clock signal that you can use to latch an input, then follow up with an interrupt. But scarschtt's question implies a foreground loop, waiting for the timer to hit a value before manipulating the pin.
@scarschtt: The system timer is a peripheral, so is the same on all devices (see page 172 of the peripheral manual). If the addresses in the sample code are in the range 0x20003000..0x2000301b, that'll be what it is. The peripherals' base address has moved from 0x20000000 to 0x3f000000 on pi2/3, otherwise everything is the same (or has the clock freq changed on pi3?). On the other hand, if the particular timer you're looking at is ARM-side rather than a peripheral, you'll probably need to write new code. There are quite a few timers I'm afraid, running off various clocks. I believe some of the ARM timers are affected by the ARM's clock (so if the ARM's clock speed is reduced because of overheating, say, the timer will slow down too, or even stop if the processor is suspended - this is actually a benefit when profiling code).
[Also, when reading the system timer it's not possible to read the high and low words simultaneously, so the low word could wrap between reading low and high - very rare and you'll never be able to reproduce the bug! I normally read the timer like this: 1) B=hi; 2) A=lo; 3) C=hi; 4) if B==C, stop (timer is in A and B); 5) B=C; 6) goto 2.]