2016-06-15 15 views

Antwort

2

Ja, Der Out-of-Order-Kern in modernen Mikroarchitekturen funktioniert grundsätzlich gleich, unabhängig vom Modus. Der größte Unterschied liegt in den Decodern. Unter Agner Fog's microarch pdf und anderen Links im Tag-Wiki erfahren Sie, wie moderne CPUs intern funktionieren.

Es würde wahrscheinlich extra Silizium benötigen, um sich im 16-Bit-Modus anders zu verhalten, da es dem 32-Bit-Modus mit deaktiviertem Paging sehr ähnlich ist, aber mit einer anderen Adressgröße und Operandengröße.

Ich habe gelesen, dass AMD-CPUs etwas langsamer sind, wenn Segmente eine Basis ungleich Null haben. (Oder ich denke, in 16-Bit-Modus. Wenn Segmentregister sich auf Werte ungleich Null gesetzt werden, da in 16-Bit-Modus sie direkt gewohnt sind, anstatt die Selektoren für die Deskriptoren zu sein)


Beachten Sie, dass many common 16bit idioms like loop are terrible .

Auch Verzögerungen bei Teilregistern können leicht die Out-of-Order-Ausführung beeinträchtigen, wenn Sie nicht vorsichtig sind. Intel P6-Familien- und SnB-Familien-CPUs benennen Teilregister separat um, sodass das Schreiben auf AX keine falsche Abhängigkeit vom gesamten Inhalt von EAX/RAX hat. Es kann zu Ständen kommen, wenn man später CPUs vor SnB zusammenfasst, oder nur geringe Verlangsamungen auf SnB vor Haswell.

Alle anderen Mikroarchitekturen behandeln mov ax, 5 als Read-Modify-Write von eax, so dass es nicht die Abhängigkeitskette auf dem alten Wert von ax brechen. Dies kann ein großes Problem für die Out-of-Order-Ausführung sein, wenn Sie nicht vorsichtig sind.

Lesen Sie die Handbücher von Agner Fog, um mehr zu erfahren.

16-Bit-Adressierungsmodi funktionieren möglicherweise nicht gut, ich vergesse. 32-Bit-Code benötigt sie nicht, um schnell zu sein, und 64-Bit-Code kann 16-Bit-Adressen überhaupt nicht verwenden. (Die Adresse-size-Präfix in 64-Bit-Codemittel Adresse-size = 32 Bits.)


VEX-codierte Befehle (einschließlich BMI2 Integer-Befehle like pext) im realen Modus nicht verfügbar sind. This Intel forum topic schlägt vor, dass aufgrund bestehender Software (NTVDM) der Maschinencode als Trap zum geschützten Modus verwendet werden kann. (d. h. die gleichen illegalen Operanden für LDS/LES, die VEX verwendet). Das Erstellen von VEX-kodierten Befehlen erzeugt immer noch #UD ist daher wichtig für die Rückwärtskompatibilität.

SSE ist immer noch im Realmodus verfügbar, if you enable it with the right CR setting.

+1

Ich lerne immer so viel vom Lesen Ihrer Antworten, auch wenn ich bereits die Antwort auf die Frage kenne! :) Zum Beispiel war mir nicht bewusst, dass VEX-codierte Anweisungen im Real-Modus nicht verfügbar waren. –

+0

@CodyGray: SO wäre ein ziemlich langweiliger Ort, wenn Antworten nicht außerhalb der Linien in verwandte Informationen gehen würden: D. Ich wollte dem Grund auf den Grund gehen, warum einige Anweisungen im Realmodus für eine Weile nicht verfügbar waren. Das Anweisungssatz-Handbuch dokumentiert diese Tatsache für einige BMI/BMI2-Integer-Anweisungen, aber nicht für AVX2-Anweisungen wie "VPBLENDD". Ich war mir nicht sicher, bis ich endlich beim Schreiben dieser Antwort gesucht habe.Ich fragte mich, ob es etwas damit zu tun hatte, nicht in 16-Bit-Operandengröße verfügbar zu sein und Operandengrößenpräfixe zu ignorieren, statt zu verlangen, dass man Transistoren brauchte. –

+1

0xc4 0xc4 0x60 (Vm-Versionsnummer) und 0xc4, 0xc4, 0x58 waren in 16-Bit-Code in der Mitte der 90er Jahre in ziemlich weit verbreitet, sogar vor NTVDM. Sie wurden häufig von denen verwendet, die versuchten herauszufinden, ob wir in SoftPC arbeiteten. Damals waren sie nur spärlich als BOP-Codes dokumentiert. Microsoft hat sie Mitte der 90er Jahre mit dem Treiber-Kit für NT-Geräte halb dokumentiert. Dies war nicht überraschend, da NTVDM auf SoftPC basierte. Ich habe die alte NT DDK CD herausgezogen und sie kann in der Datei ISVBOP.h gefunden werden. –