¿Hay alguna diferencia entre las instrucciones de ensamblaje de MCU ARM de dos corporaciones diferentes?

Tengo curiosidad por saber, ¿hay alguna diferencia entre las instrucciones de ensamblaje de los MCU ARM de dos corporaciones diferentes? Por ejemplo entre un Cortex-M3/4 de NXP y TI o ST u otras corporaciones.

Algunos de mis amigos me dicen que no tienen ninguna diferencia. ¿Es eso correcto?

Las instrucciones principales deben ser las mismas. Las instrucciones periféricas pueden variar.
@IgnacioVazquez-Abrams ¿Qué quiere decir con "instrucciones periféricas"? El Cortex-M es una arquitectura de carga/almacenamiento y no hay instrucciones especiales para E/S.
@IgnacioVazquez-Abrams aaaammm... Una cosa que es muy interesante para mí es la unidad de punto flotante. la wikipedia dice que es opcional (para Cortex-M4). entonces creo que las instrucciones básicas no son necesariamente las mismas.
@JoeHass: no tengo mucha experiencia con el conjunto de instrucciones ARM, pero como ejemplo de una arquitectura diferente, algunos procesadores AVR32 admiten el cifrado DES y AES en un periférico separado con códigos de operación específicos que no figuran en el manual genérico de AVR32.
No estoy seguro de cuándo se introdujeron instrucciones de menos de 32 bits en el núcleo ARM. Puede haber una diferencia también.
Roh, siento ser quisquilloso, pero usamos "es" cuando nos referimos a una palabra singular (diferencia) pero "son" cuando nos referimos a varias (diferencias). Entonces, el título y la primera oración de la pregunta son correctos aunque no sean lo mismo. (En un caso preguntando "¿Hay alguna diferencia?" pero en el otro preguntando "¿Hay alguna diferencia?"). Confuso, quizás pedante, pero por eso lo edité de nuevo. :)

Respuestas (3)

Creo que lo correcto es decir que para una arquitectura determinada, como la arquitectura ARMv7-M del núcleo Cortex-M3, el conjunto de instrucciones es el mismo para todos los procesadores. Sin embargo, el comportamiento de algunas instrucciones puede variar debido a la funcionalidad definida por la implementación (es decir, opcional) en el procesador. Las instrucciones que intentan acceder a capacidades opcionales que no están implementadas en un procesador en particular pueden causar excepciones.

Para encontrar las funciones que pueden definirse mediante la implementación, busque el Manual de referencia de la arquitectura ARM apropiado para IMPLEMENTACIÓN, en todas las mayúsculas.

Además, el tiempo puede variar, dependiendo de la velocidad de las memorias y los buses.
@starblue El Manual de referencia de arquitectura ARMv7-M especifica los ciclos de tiempo de ejecución (en reloj) para las instrucciones, por lo que la variación será en la frecuencia del reloj en lugar de en el nivel de instrucción. Si tiene un contraejemplo específico en mente, por favor cuéntenoslo.
He programado bucles de retardo en LPC13xx y LPC17xx (ambos Cortex-M3), y LPC17xx es aproximadamente el doble de rápido. Generalmente, la memoria flash tiene estados de espera, mientras que la RAM interna no, lo que resulta en una ralentización de un factor de tres para un LPC43xx de 200 MHz (Cortex M4).
Sin tratar de ser argumentativo, sino simplemente curioso... ¿los bucles de retardo en LPC13xx y LPC17xx implicaron accesos a la memoria dentro del bucle o simplemente registraron operandos? Cuando dice que el LPC17xx es el doble de rápido, ¿se refiere al tiempo real o al número de ciclos de reloj?
Los accesos a la memoria eran solo para el programa si no recuerdo mal. La diferencia de velocidad fue en ciclos de reloj, la diferencia real fue mayor porque LPC17xx funciona con un reloj más rápido. Creo que en LPC17xx hay más esfuerzos para acelerar el acceso flash mediante la búsqueda previa y el almacenamiento en caché.
Un caso extremo: en algunos controladores NXP, el reloj en tiempo real funciona a 1 Hz. El primer acceso de registro por segundo pasa sin ralentizar el procesador, el siguiente tiene que esperar al siguiente ciclo de reloj, lo que puede detener el procesador hasta por un segundo. :-(

Los procesadores dentro de la misma familia (por ejemplo, Cortex M3) deben tener las mismas instrucciones, pero las diferentes familias tienen instrucciones diferentes. El ARM original usaba un conjunto de instrucciones de 32 bits, luego apareció una versión que podía cambiar entre el modo "ARM" y el modo "Thumb", y este último implementaba un conjunto más pequeño de instrucciones de 16 bits. Un trabajo que requiere la mitad de las instrucciones Thumb que las instrucciones ARM requerirá aproximadamente la mitad de tiempo para ejecutarse en el modo Thumb que en el modo ARM, pero cabe en 3/4 del espacio.

Muchos procesadores más nuevos no tienen ningún modo de 32 bits, pero algunos pueden combinar dos palabras de instrucción consecutivas de tal manera que produzcan la mayoría de las instrucciones del conjunto de instrucciones ARM de 32 bits, y algunas más. Tenga en cuenta que algunas instrucciones ARM de 32 bits no están implementadas. El efecto neto es que no hay un procesador que pueda realizar todas las instrucciones ARM; diferentes familias ARM tienen diferentes conjuntos de instrucciones disponibles.

Hay una serie de variaciones diferentes en el conjunto de instrucciones ARM (consulte http://en.wikipedia.org/wiki/ARM_architecture para obtener más detalles), y las partes de diferentes proveedores pueden admitir diferentes subconjuntos.

Solo como ejemplo, no hay instrucción de división de enteros en ARMv6; es opcional en algunas versiones de ARMv7, obligatorio en otras; y presente en ARMv8.

Además, un proveedor que fabrica su propia CPU con licencia ARM puede, en principio, agregar o eliminar cualquier instrucción que desee.

Dudo mucho que ARM permita que un proveedor elimine instrucciones y aún llame a la CPU un procesador ARM. ¿Puede dar un ejemplo de esto? Sé que es técnicamente factible, solo dudo que sea legalmente permitido.
No tengo un ejemplo, pero no veo por qué a ARM le importaría siempre que se les pague, particularmente en una aplicación integrada cerrada.
Les importaría la compatibilidad, especialmente con compiladores y cadenas de herramientas.