Even if the CPUs of the new device are binary compatible with the legacy device (i.e. capable of executing programs created for the legacy device), differences in performance characteristics between the CPUs of the new device and the CPUs of the legacy device may cause errors in legacy applications, and as a result the new device will not be backwards compatible.
If the CPUs of the new device have lower performance than the CPUs of the legacy device, many errors in a legacy application may arise due to the inability to meet real time deadlines imposed by display timing, audio streamout or the like. If the CPUs of the new device have
substantially higher performance than the CPUs of the legacy device, many errors in a legacy application may arise due to the untested consequences of such high speed operation. For example, in a producer-consumer model, if a consumer of data (e.g. the CPU) operates at higher speed than originally anticipated, it may attempt to access data before the data producer (e.g. some other component of the computer) makes it available. Alternatively if the producer of the data (e.g. the CPU) operates at higher speed than originally anticipated, it may overwrite data still being used by the data consumer (e.g. some other component of the computer).
Additionally, as speed of execution of code by a CPU depends on the characteristics of the specific code being executed, it is possible that the degree of increase of performance of the CPUs of the new device relative to the legacy device will depend on the specific code being executed. This may lead to problems in the producer-consumer model described above, where producer and consumer are both CPUs but are executing the code of the legacy application at relative speeds not encountered on the legacy hardware.