In 2011 ARM made an anouncement of the first AARCH64 CPU's, then in 2015 and 2016 mainstream desktop computers using these new CPU's came to be. Since we have seen devices made without support for the true 32-bit ARM ISA. The only thing that the AARCH64 CPU has in common with ARM is the company that licenses it, and in some cases support for the 32-bit ISA. Where does that leave those that prefer what is now called AARCH32, what we have always known as the ARM ISA?

We will see in time, though this author feels that the future of True ARM (32-bit classic ARM) is in the hands of the hobbyist designers. We already have things like Amber Core and similar, the ISA can be kept alive by this means. Though there is also keeping existing ARM based computers running, be they Archimedes, A-Series, PowerPC, Touchbook, BeagleBoard, Raspberry Pi (BCM2835 and BCM2836 based), IYONIX, etc. These devices are quite capable computers still today, some may be more limited in usefulness than others, they are still great computers.

For those that still see the advantages of an ISA where all instructions are conditional, where shifts and rotates are free as part of any standard ALU instruction, for those that love the ARM ISA there will always be some kind of options available. ARM is like the 680x0 in that it has a loyal following and thus will not be allowed to die, while ARM Ltd. may move away from our beloved ISA, we will always be here to keep it going.

For those that know the Classic ARM ISA it is an ISA we really want to survive for what it has that others do not, and how eloquent the ISA is from an Assembly Language Programming perspective. Some of the highlights of what makes ARM great as a RISC CPU include:

• Instruction size always known at 32-bits, and always 32-bit word aligned in memory.
• All instructions are conditional (a few exceptions in newer ARM versions, very few).
• Shift and Rotate are free as part of normal data manipulation and ALU instructions.
• Store/Load Multiple Register instructions.
• SWI and its comment field are used for system calls in many Operating Systems.
• Well thought instructions for coprocessor interfacing.
• Good setup for privileged modes as separate depending on reason for entering privileged modes.
• SWP atomic Instruction, with external pin for exclusive access allowing simple multiple CPU setups (they forgot about this).
• Instructions that make many advanced operations simple.
• Able to achieve good code density despite being RISC with fixed 32-bit instruction word.

Some that know newer ARM CPU's will note that many of these advantages are no longer present with the non-ARM AARCH64 stuff. This adds to the push to keep the Classic ARM 32-bit ISA going strong. Some of these have even been dropped from the legacy 32-bit mode of newer CPU's from ARM. Thus we must push to keep the Classic ARM 32-bit ISA alive.

Here in the USA that all patents on ARMv2 and ARMv3 have expired (and here in the USA they can not be retroactively applied for, as prior art is provable), ARMv4 should be old enough also for its patents to have expired. We have proven that the ISA can be implemented without complaint in commercial products (there are commercial emulators written without a license from ARM for ARMv3/ARMv4 systems) so that is not an issue. To be safe it is best to use a new design to implement the ISA, as is done with Amber Core and some others. By implementing the ISA in a new design we can take advantage of newer understandings in the technology of implementation, making more modern CPU's even with the older ISA.

We all know the advantages of a split separate Data and Instruction cache. The one issue this is known to cause on the ARM is that it is common for Operating Systems to use the low 24 bits of the SWI instruction as the system call number, thus meaning having to read code as data. There is a simple solution to this issue, that is easy to implement, that solution is to have a dedicated regiseter in the CP15 system coprocessor that holds the most recent SWI instruction executed. Then it is a simple coprocessor register transfer to get the data. This could have easily been done before any ARM CPU had a split L1 cache, why ARM did not do it will never be known.

Regardless of if we use a combined R15 (Program Counter) with Status Register (SR) bits or separate R15 and SR the address space on 32-Bit Classic ARM can be much greater than many seem to think. With the combined R15 and SR code has to be mapped into the first 64MB do to the limited size of R15, though the direct address Data space can be up to 4GB and code can be mapped down by the MMU.

Starting with the ARMv3 it has been possible to have a direct address Data space of up to 4GB while R15 is combined with SR. This only puts the limit of currently running code must be in the first 64MB. The MMU can map higher addresses down to the code space if needed. Do to RISC OS mapping tasks in and out of an area with a constant base address, this means that it is possible for RISC OS to have more than 64MB of ARM Code in RAM and usable at a time, even with the combined R15 with the SR. This is also why starting with RISC OS 3.5 we got Dynamic Areas (separate the data space from the code space if more than 28MB of combined space is needed).

Regardless of which model is used for the SR the MMU can allow for much greater address spaces, with many common ARM MMUs allowing up to 1TB of address space, and some as much as 64TB of address space. As at this time high end computers only have up to 64GB of RAM (one-sixteenth of one TB) it is unlikely that we will need the available address space any time soon. This is true for the 26-bit effective R15 with combined R15 as well, the MMU can map any of the up to 64TB into the lower 64MB of address space.