Well I'd be surprised if those PowerPCs had an interrupt latency of ~10 cycles. Cortex-R cores are used in hard realtime tasks like flying the heads of a HD. Typically when you have caches latencies go up to hundreds of cycles. This is due to having many outstanding cache misses and writebacks in flight - you can't just drop those on an interrupt as you end up in an inconsistent state...

All new cores like Cortex-A7, A12 and A15 have division. Cortex-A8/A9 don't have divide as division was introduced well after they were finished. I agree it's not ideal but then again around 10 years ago, when I talked to an ARM hardware guy and asked how fast he could implement division on something like ARM11, his answer was "about 40 cycles". I then said "well my software division easily beats that with an average time below 30 cycles, so don't even bother". It seems that after the introduction of Cortex-M3 with its amazingly fast division hardware designers made division fast enough on higher-end cores as well!

The issue with running an RTOS on an -A core is that interrupt latency is much higher on fast OoO cores with large caches. So you lose the R in RTOS. The -R cores have special features to keep interrupt latency low (although to get the lowest interrupt latency you have to use an -M core).

Actually, I'd say no. There are a lot of CPUs arround with cache which are used in realtime enviroments (like all the automotive PowerPCs).

All Cortex-A cores since A15 do have integer divide. The latest QC and Apple cores do have divide as well.

The thing is, Cortex-R4 has it, but e.g. ZYNQ Cortex-A9 does not have it as it is "optional".

In an ARMv7-A implementation that does not include the Virtualization Extensions, the implementation of SDIV and UDIV in both instruction sets is OPTIONAL, but the architecture permits an ARMv7-A implementation to not implement SDIV and UDIV.

So what? I really wonder, what goes on in the brains of architecture developers (and as it is optional: implementers) :-(

The R variant of the architecture has always been something of a middle ground, with some -M features and some -A features. That's just what the RTOS people seem to need.

If you want 32 registers then you do want 64-bit but use 32-bit pointers to avoid the overhead of 64-bit pointers. For x64 there is already a Linux ABI with 32-bit pointers, so I bet there will be one for ARM64 as well.

The issue with running an RTOS on an -A core is that interrupt latency is much higher on fast OoO cores with large caches. So you lose the R in RTOS. The -R cores have special features to keep interrupt latency low (although to get the lowest interrupt latency you have to use an -M core).

All Cortex-A cores since A15 do have integer divide. The latest QC and Apple cores do have divide as well.

Ok, reading this document shows really some improvements over v7R.But it again makes me wonder why ARM differs -A and -R but now they mix -A and -R with the v8-R only that there is no 64bit support (which I do not miss) and no support for the new ISA with 32 registers (which I miss).Granted, todays feature rich (overloaded?) OSes will not run on a R or M CPU, but on the other hand, an RTOS very well runs on an A one.

I really wonder: Do the ARM ISA developers talk to (RT)OS designers asking what they think an ISA needs? I mean, how come an Cortex-A CPU does not have integer divide? (Ok, now going off-topic...)

So lets wait for the first dual-core v8-R (no more Cortex I guess) CPU.

This is the v8 version of the v7-R architecture. So it is indeed compatible with existing cores like Cortex-R4 but adds new features as well, such as the Hypervisor and support for running Linux. Note v8-R is not 64-bit.