Gibt es einen Unterschied zwischen den Montageanleitungen von ARM-MCUs von zwei verschiedenen Unternehmen?

Ich bin neugierig zu wissen, gibt es Unterschiede zwischen den Montageanleitungen von ARM-MCUs von zwei verschiedenen Unternehmen? Zum Beispiel zwischen einem Cortex-M3/4 von NXP und TI oder ST oder anderen Konzernen.

Einige meiner Freunde sagen mir, dass sie keinen Unterschied haben. Ist das korrekt?

Kernanweisungen sollten gleich sein. Peripherieanweisungen können variieren.
@IgnacioVazquez-Abrams Was meinst du mit "peripheren Anweisungen"? Der Cortex-M ist eine Load/Store-Architektur und es gibt keine speziellen Anweisungen für I/O.
@IgnacioVazquez-Abrams aaaammm ... Eine Sache, die für mich sehr interessant ist, ist die Gleitkommaeinheit. Die Wikipedia sagt, dass es optional ist (für Cortex-M4). dann denke ich, dass die Kernanweisungen nicht unbedingt die gleichen sind.
@JoeHass: Ich habe nicht viel Erfahrung mit dem ARM-Befehlssatz, aber als Beispiel einer anderen Architektur unterstützen einige AVR32-Prozessoren die DES- und AES-Verschlüsselung in einem separaten Peripheriegerät mit bestimmten Opcodes, die nicht im generischen AVR32-Handbuch aufgeführt sind.
Nicht sicher, wann kürzere Anweisungen als 32 Bit in den ARM-Kern eingeführt wurden. Es kann auch einen Unterschied geben.
Roh, entschuldigen Sie die Kleinigkeit, aber wir verwenden "ist", wenn wir uns auf ein einzelnes Wort (Unterschied) beziehen, aber "sind", wenn wir uns auf mehrere (Unterschiede) beziehen. Der Titel und der erste Satz der Frage sind also beide korrekt, obwohl sie nicht identisch sind. (In einem Fall fragen Sie "Gibt es Unterschiede?", im anderen Fall "Gibt es Unterschiede?"). Verwirrend, umständlich vielleicht, aber deswegen habe ich es nochmal editiert. :)

Antworten (3)

Ich denke, das Richtige ist, dass für eine bestimmte Architektur, wie die ARMv7-M-Architektur des Cortex-M3-Kerns, der Befehlssatz für alle Prozessoren gleich ist. Das Verhalten einiger Befehle kann jedoch aufgrund der implementierungsdefinierten (dh optionalen) Funktionalität im Prozessor variieren. Anweisungen, die versuchen, auf optionale Fähigkeiten zuzugreifen, die in einem bestimmten Prozessor nicht implementiert sind, können Ausnahmen verursachen.

Um die Features zu finden, die für die Implementierung definiert werden können, suchen Sie im entsprechenden ARM-Architektur-Referenzhandbuch nach IMPLEMENTATION, in Großbuchstaben.

Außerdem kann das Timing in Abhängigkeit von der Geschwindigkeit der Speicher und Busse variieren.
@starblue Das ARMv7-M-Architekturreferenzhandbuch gibt die Ausführungszeit (in Taktzyklen) für die Anweisungen an, sodass die Variation eher in der Taktfrequenz als auf der Befehlsebene erfolgt. Wenn Sie ein konkretes Gegenbeispiel im Sinn haben, teilen Sie uns dies bitte mit.
Ich habe Verzögerungsschleifen auf LPC13xx und LPC17xx (beide Cortex-M3) programmiert, und LPC17xx ist etwa doppelt so schnell. Im Allgemeinen hat Flash-Speicher Wartezustände, während internes RAM dies nicht tut, was zu einer Verlangsamung um den Faktor drei für einen 200-MHz-LPC43xx (Cortex M4) führt.
Ich versuche nicht, argumentativ zu sein, sondern bin nur neugierig ... beinhalteten die Verzögerungsschleifen auf dem LPC13xx und LPC17xx Speicherzugriffe innerhalb der Schleife oder nur die Registrierung von Operanden? Wenn Sie sagen, dass der LPC17xx doppelt so schnell ist, meinen Sie damit die Echtzeit oder die Anzahl der Taktzyklen?
Die Speicherzugriffe waren nur für das Programm, wenn ich mich recht erinnere. Der Geschwindigkeitsunterschied lag in Taktzyklen, der tatsächliche Unterschied war größer, weil LPC17xx auf einem schnelleren Takt läuft. Ich denke, auf LPC17xx gibt es mehr Bemühungen, den Flash-Zugriff durch Prefetching und Caching zu beschleunigen.
Ein Extremfall: Bei manchen NXP-Controllern läuft die Echtzeituhr mit 1 Hz. Der erste Registerzugriff pro Sekunde kommt durch, ohne den Prozessor zu verlangsamen, der nächste muss auf den nächsten Taktzyklus warten, der den Prozessor bis zu einer Sekunde lang anhalten kann. :-(

Prozessoren innerhalb derselben Familie (z. B. Cortex M3) sollten dieselben Anweisungen haben, aber verschiedene Familien haben unterschiedliche Anweisungen. Der ursprüngliche ARM verwendete einen Satz von 32-Bit-Anweisungen, dann erschien eine Version, die zwischen dem „ARM“-Modus und dem „Thumb“-Modus wechseln konnte, wobei letzterer einen kleineren Satz von 16-Bit-Anweisungen implementierte. Ein Job, der noch einmal halb so viele Thumb-Befehle benötigt wie ARM-Befehle, dauert im Thumb-Modus noch einmal ungefähr halb so lange wie im ARM-Modus, passt aber in 3/4 des Platzes.

Viele neuere Prozessoren haben keinen 32-Bit-Modus, aber einige können zwei aufeinanderfolgende Befehlswörter so kombinieren, dass sie die meisten Befehle aus dem 32-Bit-ARM-Befehlssatz und einige mehr liefern. Beachten Sie, dass einige 32-Bit-ARM-Befehle nicht implementiert sind. Der Nettoeffekt ist, dass es keinen Prozessor gibt, der jeden ARM-Befehl ausführen kann; Unterschiedliche ARM-Familien verfügen über unterschiedliche Befehlssätze.

Es gibt eine Reihe verschiedener Variationen des ARM-Befehlssatzes ( Einzelheiten siehe http://en.wikipedia.org/wiki/ARM_architecture ), und die Teile verschiedener Anbieter unterstützen möglicherweise unterschiedliche Teilsätze.

Nur als Beispiel gibt es in ARMv6 keine Integer-Divisionsanweisung; es ist in einigen Versionen von ARMv7 optional, in anderen obligatorisch; und in ARMv8 vorhanden.

Darüber hinaus kann ein Anbieter, der seine eigene ARM-lizenzierte CPU herstellt, im Prinzip alle Anweisungen hinzufügen oder entfernen, die ihm wichtig sind.

Ich bezweifle sehr, dass ARM einem Anbieter erlauben würde, Anweisungen zu entfernen und die CPU trotzdem als ARM-Prozessor zu bezeichnen. Können Sie dafür ein Beispiel nennen? Ich weiß, dass es technisch machbar ist, ich bezweifle nur, dass es rechtlich zulässig wäre.
Ich habe kein Beispiel, aber ich verstehe nicht, warum sich ARM darum kümmern sollte, solange sie bezahlt werden, insbesondere in einer geschlossenen eingebetteten Anwendung.
Sie würden sich wegen der Kompatibilität, insbesondere mit Compilern und Toolchains, darum kümmern.