What is the value of r3 on entry to a device interrupt handler?

The wiki claims that on entry to a device interrupt handler “R3 points to the base of the IO controller chip memory space”, the kernel passes the value of r3 returned by HAL_IRQSource which is documented to leave the value of r3 undefined.

So which is correct?

The IOMD HAL and Tungsten HAL return the value “IOMD_Address”.

The OMAP4 HAL sets r3 to zero or one, and the BCM2835 HAL leaves r3 unaltered.

Would the appropriate fix be to document the r3 is passed from the HAL to the interrupt handler and that on IOC and IOMD (including ARM7500) based machines it is “the base of the IO controller chip memory space”?

I’d assume R3 is undefined under RISCOS5. On IOC/IOMD pre RISCOS5, R3 is the IO controller base as you’ve stated.

I’ve altered the wiki to document the current situation with R3 being undefined on non-IOMD machines.

Correct, R3 is undefined under RISC OS 5.

I’ve revised the wiki some more, to bring it more in line with the RISC OS 5 API.

Note that the kernel breaks its own rules by corrupting R11 in a couple of its IRQ handlers.

I have a feeling that the IOMD & Tungsten behaviour of returning the IOMD base address in R3 was only for the purpose of easing initial development of RISC OS 5 – not for easing compatibility with third-party software once the OS was released. After all, device drivers should be implemented in modules, and all modules would have needed to be updated to add the 32bit flag to the header (+ probably many other updates to ensure 26/32bit neutral operation).