Adrian (a@acm.org) on 1/14/11 wrote:
---------------------------
>Paul (no@thanks.com) on 1/13/11 wrote:
>>
>>The M profile architecture was designed specifically for the micro-controller market.
>>It is binary compatible with user space Thumb code written for an ARMv4T as Thumb2 contains Thumb1.
>>
>>However at the system level the exception model for the M profile is totally different
>>and it does not support ARM state.
>>
>>The statement about ARM binary compatibility should be made about Application Processors.
>>That is to say those with an MMU which are capable of running a virtual memory OS.

No, that's wrong. Binary compatibility is related to ISA versions, not to whether a CPU has an MMU or caches etc. Of course, binary compatibility is far more essential in the application processor space, but that is a different matter.

>You are of course completely right, but Wilco did not qualify in any way his claims.
>As they were written, they were misleading for anyone that is unfamiliar with ARM.

Come on. Nobody sane expects to run ARM code on ARMv7-M in the same way nobody expects to run Neon code on a CPU that doesn't support it. Basically v7-R and v7-A provide 100% binary compatibility with older architectures, while v7-M is a new branch in the architecture which is 100% binary compatible with Thumb-1 code from previous architectures but not with ARM.

So yes, it's a little more complex than just comparing the architecture number (and I suspect most people understand this) but it is a lie to claim there is no binary compatibility when in reality the compatibility is 100%. Not all CPUs implement the same features - this unavoidable in the huge space that ARM spans from tiny 10MHz embedded cores to 2GHz application CPUs.

>Identical claims can be made about the x86 processors, and when someone points
>to some counter-examples, you can retract and say that you really meant only processors
>designed by Intel and that are not some kind of Atom.

The problem with x86 is that there isn't even an official architecture definition. Both AMD and Intel just haphazardly add new instructions whenever they want - and they do so with every new version. There are 20+ different incompatible variants of the x86 instruction set being in active use even if we just consider mid/high-end and ignore Atom, VIA, embedded 386/486 cores (yes they still exist) etc.

Contrast this with ARM, where all high-end CPUs (Cortex-A8, Scorpion, Armada, Cortex-A9 etc) use EXACTLY the same instruction set. So believing that x86 is somehow more binary compatible than ARM is just a delusion.

>My old user-space ARM programs were a mixture of Thumb and ARM procedures, so they
>cannot be run without recompilation on the current ARM processors that are designed
>for exactly the same application, therefore there exists no binary compatibility.

You can run your old code on new ARM CPUs, so binary compatibility exists. The fact there are also some CPUs which do not run your code doesn't mean there is no binary compatibility at all. If there was no binary compatibility then you could not run your code on ANY new CPU. And that is clearly not the case.

>Nonetheless, for controller applications there is no disadvantage in this. If it
>lowers the power consumption, it is a clear advantage.

Absolutely, it was the correct decision. The particular market for Cortex-M3/M0 was new and thus most design wins are from 8/16-bit architectures. Due to codesize, ARM is the wrong ISA for this and would increase the size/cost/power of the M3/M0 enough to make it less competitive. 99% of code that runs on ARM7tdmi is already Thumb-1, so it is easy to migrate. For the few cases where ARM is used, you'd need to recompile or reassemble (you don't need to rewrite your ARM assembler as it can reassemble into Thumb-2 with little effort).

>>I resent having to buy a processor that wastes resources for this, just
>>because I need another feature that is implemented by that architecture version.

Paul already addressed part of this. Only very expensive features should be optional. For medium cost features the correct approach is to allow a choice between say a fast VFP and a simple, small VFP, but not allow the option of having no floating point support at all.

You won't save significant power or area by removing low-cost features you don't use. CPU design work and risk would increase and all permutations need to be tested. It would be a nightmare for manufacturers as you now need to build many variants of the same core.

At the end of the day, the cost of features like Jazelle is small, it's already a tiny fraction of the core but once you consider caches, peripherals, on-chip flash etc it is insignificant. But the gain you get when it is used is huge. So the cost/benefit means that all low-cost features should be implemented by default.

Wilco