ARM architecture versions cheat sheet

Note: only changes of direct practical relevance to RISC OS are mentioned.

Version RISC OS machines (chips used) Significant changes

ARMv1 Prototype, never generally released -

ARMv2 Archimedes series (ARM2, ARM3, ARM250) Multiply instruction added.

ARMv3 Early RiscPCs (ARM610, ARM710) 32-bit processor modes are introduced, but the old 26-bit behaviour may be optionally emulated for compatibility. Acorn switched on this emulation and never bothered updating RISC OS to use the 32-bit modes.

ARMv4 Later RiscPCs (StrongARM, Kinetic) The StrongARM had separate caches for code and data, which meant self-modifying code no longer worked. It also contained a large number of bugs.

ARMv5 (also ARMv4T) Iyonix PC (XScale) (also A9home) The 26-bit emulation is removed. Suddenly RISC OS and its applications are forced to run in 32-bit mode. Probably the most significant compatibility barrier ever surmounted.

ARMv6 Raspberry Pi (BCM2835) The outcome of loading and storing words to and from non-word-aligned addresses changes, but the old behaviour may be optionally emulated for compatibility. The ability is also added to raise an abort instead of doing the load or store.

ARMv7 BeagleBoard (OMAP3), PandaBoard (OMAP4) The emulation of the old alignment behaviour is removed. The only options are now the new, non-compatible behaviour ("alignment exceptions off") or a crash ("alignment exceptions on").

ARMv8 Announced, but no chips yet available Introduces an entirely new, 64-bit instruction set which would necessitate the complete rewriting of RISC OS and all its software from the ground up. Capable of emulating the old one for now, but how long is that going to last...?

This is a simple table, aimed primarily at RISC OS users without much programming knowledge, which I put together to provide a quick and dirty reference to the different versions of the ARM architecture, the RISC OS computers they have been used in, and how it affects software compatibility.

Unless you're an assembly programmer, you don't have to worry too much about what the technical details mean, but these are the key take-home facts:

"32-bit compatible" refers to an application which will run on ARMv5 or later.
All hardware since the RiscPC has been equally capable of being just as incompatible as an Iyonix. It's just that Acorn chose not to allow it. Only since the Iyonix has it been compulsory.
RISC OS 5 is the 32-bit fork of RISC OS. It always runs in 32-bit mode, regardless of what computer it is running on. It has been backported to the RiscPC (and A7000), largely so that those machines can enjoy the fruits of a free, continuously developed OS, but it will not provide any of the compatibility benefits of running RISC OS 3 or 4 on the same machine.
"ARMv7 compatible", "BeagleBoard compatible" and "ARMv6/v7 compatible" all mean the same thing.
A Raspberry Pi can be configured to be as incompatible as a BeagleBoard, but this is generally only useful if you are testing software. It is otherwise more or less equivalent to the Iyonix in terms of what software is likely to work. BeagleBoard (and PandaBoard) owners get no choice in the matter.

This document should not be considered canonical - its intention is to provide a simple, minimal understanding of the basics, rather than a comprehensive guide to the ins and outs of the whole situation. There are, in other words, a number of footnotes and caveats which I felt it inappropriate to include, for fear of making the whole too daunting.

An oddity worth noting is that RISC OS ran on an ARMv7 computer (the BeagleBoard) before it ran on an ARMv6 one (the Raspberry Pi). This is because development and support of the OS slowed to such a crawl in the mid-2000s that it completely missed ARMv6 while that version was current, and by the time it began to pick up steam again with the RISC OS Open project, it had already been superseded by ARMv7. The Raspberry Pi is ARMv6 because it uses outmoded, dirt cheap hardware which could be bought for 25,ドル not because it is any older than the BeagleBoard.

As RISC OS has always been a single-architecture system, still largely written in assembly language, it has been much more vulnerable to changes in the ARM standard over the years than most other OSes. Most long-term users are aware of the rough timeline of problems caused by the introduction of new hardware, necessitating extensive updates both to RISC OS itself and a large part of all software which ran on it:

1987: First Archimedes computer released.
1994: First RiscPC released. Much old software breaks - although mainly due to changes in other hardware rather than the processor itself - and has to be updated. A lot (principally games, never bastions of good coding practice) never becomes compatible, due to the shrinking market.
1996: StrongARM upgrade for RiscPCs released. Most remaining software breaks and has to be updated. Again some never makes it, due to the shrinking market.
2003: Iyonix PC released. Almost all old software breaks and has to be updated. A hefty proportion is left behind, as the 'market' is now too small to be worthy of the term.
2009: RISC OS updated to run on the BeagleBoard, and some other development boards as well. A significant proportion of the tiny amount of software still functional once again breaks. The owning companies of both forks of RISC OS are effectively dead and very little software is still maintained.

Finally, remember that this document only covers the incompatibilities caused by changes in hardware. Sometimes OS updates also cause old software to break (e.g. some RISC OS 3 software didn't work on RISC OS 4), but these are a separate issue. Software, including the operating system itself, can always be changed, but hardware cannot.