In einigen Antworten, die ich auf Fragen zu SO geschrieben habe, sprechen sie über mikrocodierte Anweisungen. Ich habe mich gefragt, was das ist.
Kann jemand erklären, was diese sind und warum sie dort sind?
Eine CPU liest Maschinencode und dekodiert ihn in interne Steuersignale, die die richtigen Daten an die richtigen Ausführungseinheiten senden.
Die meisten Befehle werden einer internen Operation zugeordnet und können direkt decodiert werden. (z. B. auf x86, add eax, edx sendet nur eax und edx an die ganzzahlige ALU für eine ADD-Operation und setzt das Ergebnis in eax.)
Einige andere einzelne Anweisungen tun viel mehr. z.B. x86's rep movs implementiert memcpy(edi, esi, ecx) und erfordert das Schleifen der CPU.
Wenn die Befehlsdecoder einen Befehl wie diesen sehen, lesen sie nicht nur interne Steuersignale direkt, sondern lesen Mikrocode aus dem Mikrocode-ROM.
Eine mikrocodierte Anweisung dekodiert viele interne Operationen
Moderne x86-CPUs decodieren x86-Anweisungen immer in interne Mikrooperationen. In dieser Terminologie wird es immer noch nicht als "mikrocodiert" gezählt, auch wenn add [mem], eax zu einem Ladevorgang von [mem] dekodiert, eine ALU ADD-Operation und ein Speicher wieder in [mem] . Ein anderes Beispiel ist xchg eax, edx , was
Bei Intel / AMD-CPUs bedeutet "mikrocodiert", dass die Decoder den Mikrocode-Sequenzer einschalten, um Ups aus dem ROM in die Pipeline zu leiten, anstatt mehrere Ups direkt zu erzeugen.
In derzeitigen Intel-CPUs ist die Grenze, auf der die Decoder direkt produzieren können, ohne zum Mikrocode-ROM zu gehen, 4 Ups (fusionierte Domain). AMD hat in ähnlicher Weise FastPath-Befehle mit Einzel- oder Doppelbefehlen und darüber hinaus VectorPath oder Microcode, wie in David Kanters tiefem Blick auf AMD Bulldozer erklärt wird , speziell über seine Decoder.
Ein weiteres Beispiel ist der Integer-DIV-Befehl von x86, der selbst auf modernen CPUs wie Intel Haswell mikrocodiert ist. Siehe meine Antwort auf Warum ist dieser C ++ Code schneller als meine? handschriftliche Versammlung für das Testen der Collatz-Vermutung? für die Zahlen.
Die FP-Aufteilung ist ebenfalls langsam, wird aber zu einem einzigen UOP dekodiert, so dass das Front-End nicht eng wird. Wenn die FP-Aufteilung selten ist und nicht Teil eines Latenzengpasses ist, kann sie genauso billig sein wie die Multiplikation. (Aber wenn die Ausführung auf ihr Ergebnis warten muss, oder Engpässe bei ihrem Durchsatz, ist sie viel langsamer.)
Ganzzahlige Division und andere mikrocodierte Anweisungen können der CPU Schwierigkeiten bereiten, und erzeugt Effekte, die die Codeausrichtung zu etwas machen, wo es sonst nicht wäre.
Weitere Informationen zu den internen x86-CPUs finden Sie in den x86 Tag-Wiki und besonders Agner Fogs Microarch Guide .
In einigen älteren / einfacheren CPUs wurde jeder Befehl effektiv mikrocodiert. Der 6502 hat zum Beispiel 6502 Anweisungen ausgeführt, indem er eine Folge interner Anweisungen von einem PLA-Dekodier-ROM ausgeführt hat . Dies funktioniert gut für eine CPU ohne Pipeline, bei der die Reihenfolge der Verwendung der verschiedenen Teile der CPU von Befehl zu Befehl variieren kann.
Historisch gab es eine andere technische Bedeutung für "Mikrocode", was soviel bedeutet wie die internen Steuersignale, die aus dem Befehlswort decodiert wurden. Besonders in einer CPU wie MIPS, wo das Befehlswort direkt auf diese Steuersignale abgebildet wird, ohne komplizierte Decodierung. (Ich habe das teilweise falsch; ich habe so etwas gelesen (anders als in der gelöschten Antwort zu dieser Frage), konnte es aber später nicht mehr finden.)
Tags und Links assembly cpu cpu-architecture