The Kernel

RISC OS 4 has undergone some important changes. Unfortunately, these mean that the new version is specific to Phoebe, and will not be available for older machines.
There are two main enhancements to RISC OS 4's Kernel: task swapping has been improved, and 32 bit user code is now supported.

The responsibility for Task Swapping has been moved from the Window Manager into the Kernel.
A new algorithm has been implemented, known as Lazy Task Swapping. This improves the speed of context switching by only loading memory pages when they are required.
The old method of context switching hit the StrongARM's cache hard. Every time a new application was paged in, the cache had to be flushed and then reloaded from the new task's memory area. The Lazy algorithm helps to avoid this.

In addition, the Kernel now fully supports 32 bit code.
RISC OS is fundamentally a 26 bit system, a hang-over from the old ARM processors. Code running in Fast IRQ or Supervisor modes can be 32 bit at the moment, but this is not recommended.
Two new SWIs have been added to RISC OS 4 to allow user code to execute in the 32 bit mode (for example, SVC32 from the ARM Architecture v4).
One of the prime motivations for this change is that it allows the Floating-Point Emulator (FPE) to be rewritten to fully exploit the StrongARM.
The new FPE will make full use of the StrongARM's 32 bit instructions, such as the 32 bit by 32 bit multiply. This is likely to significantly improve the FPE's performance: for example, a long multiply originally took 2 to 16 clock cycles; in 32 bit mode, it will take 2 to 3 cycles. New Information
A further advantage is that the 32 bit code will run from within a Dynamic Area, offering a better memory protection model. New Information

32 bit code uses 32 bit addresses, allowing the whole of memory to be accessed.
Dynamic Areas lie outside the memory area which is accessible with 26 bit addressing. To run code in a dynamic area therefore requires 32 bit addressing.
The advantage of running code in a dynamic area is better memory protection. Writes to other dynamic areas, caused by a misbehaving routine, can be trapped before they cause damage to another piece of code. New Information

Thanks to Kade Hansson and André Timmermans for this explanation.

Unfortunately, Phoebe will not benefit from extra memory protection as originally thought.
The Memory Management Unit (MMU) is responsible for controlling programs' access to memory. In Phoebe, the MMU is part of the StrongARM SA-110 processor.
The SA-110 currently only allows dynamic areas to be read-only or unprotected. There is no way to allow one process write access, whilst blocking all others.

The Floating Point Emulator will benefit from using 32 bit mode, and not just in the speed of long multiplies.
The StrongARM in the RiscPC is normally run in 26 bit mode. However, with the SA-110, exceptions must be handled in 32 bit mode.
As a result, a typical invocation of the FP Emulator involves several mode changes:
- 26 bit User Mode: Undefined instruction is found.
- 32 bit Exception: Exception handler passes exception details to vector.
- 26 bit User Mode: FP Emulator traps and executes instruction.
- 32 bit Exception: Exit exception handler veneer.
- 26 bit User Mode: Return to original calling mode.
With a 32 bit FP Emulator, the sequence will be:
- 26 bit User Mode: Undefined instruction is found.
- 32 bit Exception: Exception handler passes exception details to vector.
- 32 bit Exception: FP Emulator traps and executes instruction.
- 32 bit Exception: Exit exception handler veneer.
- 26 bit User Mode: Return to original calling mode.
The current procedure involves four processor mode switches for each FP instruction. The new system will only require two mode switches.
In Dave Walker's words "Switching processor modes between addressing domains has a habit of eating cycles".

Thanks to Eddie Edwards and Dave Walker for this new information.