> the build of RISC OS has to be different to cope with difference within the CPU itself?
Correct. The differences are as follows (note: may not be a complete list!)
* The MMU and cache handling code in the kernel needed updating to handle the new MMU & cache type used by the Cortex. The MMU and cache differences shouldn't affect any well-behaved programs.
* Changes in the way LDR/LDM/STR/STM handle non-word aligned data loads/stores has the potential to affect many programs. So far a few OS modules have been changed, but I suspect 90% of software (espeically that written in C) will continue to work as normal.
* Finally there's VFPU support. If a program wants to make use of the hardware floating point, the easiest/best way of doing that is likely to be to recompile it (once the relevant compiler gains support for the VFP instruction set). There's the other non-easy way of modifying the FPEmulator to map old FPU instructions to new VFPU instructions, but that will be a hard (if not impossible) task and won't provide as good performance as a recompiled program would provide.
* There have also been a couple of non-32bit compatible pieces of assembler I've found in the OS that previously used to work fine but have now started to fall over. I'm not sure of the exact reason for this, but I doubt it's going to affect any other software (due to the size of the OS it was inevitable that a few bits here and there would fall through the cracks)
So although I haven't actually tried any 3rd party software yet, I believe that most, if not all well-behaved 32bit compatible software will continue to run without a hitch. Then once compiler support for VFP is available, software authors can begin to recompile their code to take advantage of the speed benefit.
Of course there's also the issue of backwards-compatability with machines that lack VFP - this will likely be handled with a new FPEmulator, or just having two different executables (which could be quite attractive now that GCC has software floating point, giving much better performance than FPEmulator on non-FP hardware)
> Which compiler is being used? Acorn C/C++ or GCC I thought the RISC OS sources required Acorn C/C++ I didn't think it had been updated for Cortex-A8 support!
The ROOL sources are still tied to Acorn C/C++, but I believe efforts are underway to improve the source (mainly in the build system and makefiles) to allow GCC to be used (either natively or with the cross-compiler). And I'm sure that both ROOL and the GCCSDK team will welcome any help that people can provide to update the Acorn/GCC compilers to support the new CPU instructions!