Adrian (a@acm.org) on 1/13/11 wrote:
---------------------------
>This is not at all true. For example now I am writing some program for processors
>that implement the ARMv7-M architecture and these are not binary compatible with
>the processors that I was using 5 years ago, which implemented the ARMv4T architecture.

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.

>ARM does not have an equivalent for the x86 CPUID, so if you happen to have a really
>old ARM processor and an ARM binary program, it can be very difficult to figure
>out if you can run the program on that processor or not.

ARM does have a CPUID mechanism however it is implemented as set of feature registers which are privileged access only. Therefore support has to be built into the OS for a user space application to be able to query what extensions to the base architecture are supported.

Although x86 allows CPUID to be executed at unprivileged levels it's not completely useful as it must be executed multiple times in sequence on the same core in order to return all the information. You generally cannot guarantee this on a pre-emptively scheduled SMP OS which is why OSes tend to have a kernel level driver to help.

>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.

I'm afraid that in the application space the majority of market wants one architecture with no optional bits. Just look at the x86 market with multiple different extensions implemented by AMD and Intel. Except in very specific circumstances(1) the only ones which gain traction are the ones which are implemented by all processors.

The lag between the introduction of an ISA extensions and use by compilers by default is huge. It's only relatively recently that the market has managed to leave Pentium/i586 class behind and require P6/i686 class(2) or better. The next milestone is to requiring SSE and therefore PIII class or better(3). You get a once in a generation opportunity to reset the baseline every so often for example x86_64 did this.

(1) Virtualistion is an exception, the Intel and AMD systems are different but since this is a system level feature and the number of hypervisor vendors is tiny the market will bear it.

(2) In actual fact this was more of realisation that they had been using P6 specific constructs for years and so few people still had lower class hardware, certain VIA chips for example, that it didn't matter.

(3) Large numbers of companies still have Pentium-M laptops in general circulation.