Warum braucht die Mac ABI 16-Byte-Stack-Ausrichtung für x86-32?
https://stackoverflow.com/questions/612443
-
03-07-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianFrage
kann ich diese Anforderung für die alten PPC RISC-Systeme verstehen und auch für x86-64, sondern für den alten erprobte und wahren x86? In diesem Fall muss der Stapel nur auf 4-Byte-Grenzen ausgerichtet werden. Ja, einige der MMX / SSE-Befehle erfordern 16Byte Ausrichtungen, aber wenn das eine Forderung des Angerufenen ist, dann sollte es sicherstellen, dass die Ausrichtungen korrekt sind. Warum Last alle Anrufer mit dieser zusätzlichen Anforderung? Dies kann tatsächlich einige Tropfen in der Leistung führen, da jeder Anruf-Website diese Anforderung verwalten müssen. Bin ich etwas fehlt?
Update: Nach einiger mehr Untersuchung dieses und einigen Konsultationen mit einigen internen Kollegen, ich habe einige Theorien dazu:
- Konsistenz zwischen der PPC, x86 und x64-Version des OS
- Es scheint, dass die GCC codegen jetzt konsequent einen Unter tut esp, xxx und dann „mov“ s die Daten auf den Stapel, anstatt einfach eine „Push“ Anweisung zu tun. Dies könnte tatsächlich schneller auf einigen Hardware.
- Während dies die Aufrufstellen ein wenig verkompliziert, es gibt sehr wenig zusätzlichen Aufwand, wenn die Standard „cdecl“ Konvention mit dem der Anrufer den Stapel bereinigt.
Das Problem, das ich mit dem letzten Punkt haben, ist, dass Konventionen für den Aufruf, der auf den Angerufenen verlassen, um den Stapel Reinigung, die oben genannten Anforderungen wirklich „uglifies“ die codegen. Zum Beispiel, was einige Compiler einen schnelleren registerbasierte calling Stil für seinen eigenen internen Gebrauch (dh jeden Code, der nicht von anderen Sprachen oder Quellen genannt werden soll) implementieren entschieden? Diese Stapel-Ausrichtung Sache, indem man einige Parameter in den Registern erreichten einige der Performance-Gewinne zunichte machen könnte.
Update: Bisher ist die einzigen wirklichen Antworten gewesen Konsistenz, aber für mich ist das ein bisschen zu einfach, eine Antwort. Ich habe mehr als 20 Jahre Erfahrung mit der x86-Architektur und wenn Konsistenz, nicht der Leistung, oder etwas anderes Beton, ist wirklich der Grund, dann schlage ich respektvoll, dass ein bisschen naiv für die Entwickler es erfordern. Sie sind zu ignorieren fast drei Jahrzehnte von Werkzeugen und Unterstützung. Vor allem, wenn sie erwarten Anbieter Werkzeuge, um schnell und einfach ihre Werkzeuge für ihre Plattform anpassen (vielleicht auch nicht ... es ist von Apple ...), ohne sich durch mehrere scheinbar unnötige Reifen springen zu müssen.
Ich werde dieses Thema geben einen anderen Tag oder so, dann schließen Sie es ...
Related
Lösung
Von "Intel®64 und IA-32 Architektur-Optimierung Referenzhandbuch", Abschnitt 4.4.2:
„Für die beste Leistung, die Streaming SIMD Extensions und Streaming SIMD Extensions 2 benötigen, um ihre Speicheroperanden in 16-Byte-Grenzen ausgerichtet werden. Unaligned Daten erhebliche Leistungseinbußen im Vergleich zu ausgerichteten Daten führen können.“
Von Anhang D:
„Es ist wichtig, um sicherzustellen, dass der Stapelrahmen zu einer Grenze von 16 Byte ausgerichtet ist auf Funktion Eintrag lokale __m128 Daten, Parameter zu halten, und XMM-Register spill Standorte in einem Funktionsaufruf ausgerichtet ist.“
Andere Tipps
Ich bin nicht sicher, wie ich nicht aus erster Hand Beweise haben, aber ich glaube, der Grund SSE ist. SSE ist viel schneller, wenn Ihre Puffer bereits an einer Grenze 16 Byte ausgerichtet sind (movps vs movups) und jede x86 mindestens SSE2 für mac os x. Es kann durch die Anwendung Anwender getroffen werden, Pflege aber die Kosten sind ziemlich bedeutend. Wenn die Gesamtkosten für die Herstellung ist es zwingend notwendig, in dem ABI nicht zu groß, kann es lohnt sich. SSE ist ziemlich pervasively in Mac OS X verwendet: beschleunigen Rahmen, etc ...
Ich glaube, es ist, es zu halten inline mit dem x86-64 ABI.
Beachten Sie zunächst, dass die 16 Byte Ausrichtung eine Ausnahme von Apple auf das System V IA-32 ABI.
eingeführt istDer Stapel Ausrichtung wird nur dann benötigt, wenn die Systemfunktionen aufrufen, da viele Systembibliotheken SSE oder Altivec Erweiterungen verwenden, die die 16 Byte Ausrichtung erfordern. Ich fand einen ausdrücklichen Hinweis in der libgmalloc MAN .
Sie können perfekt handhaben Ihr Stack den Weg umrahmen Sie wollen, aber wenn Sie versuchen, eine Systemfunktion mit einem falsch ausgerichteten Stapeln zu nennen, werden Sie mit einer am Ende misaligned_stack_error Nachricht.
Edit: Für die Aufzeichnung können Sie von Ausrichtungsprobleme loszuwerden, wenn sie mit GCC kompilieren mit der mstack-neu auszurichten Option.
Dies ist eine Effizienz Ausgabe.
Sicherstellen, dass der Stapel 16-Byte in jeder Funktion ausgerichtet, die die neuen SSE-Befehle verwendet fügt eine Menge Aufwand für diese Anweisungen verwenden, effektiv die Leistung zu reduzieren.
Auf der anderen Seite, hält den Stapel 16-Byte zu allen Zeiten ausgerichtet ist sichergestellt, dass Sie SSE-Befehle ohne Leistungseinbuße frei nutzen können. Es gibt keine Kosten zu diesem (Kosten in Anweisungen zumindest). Es handelt sich nur um eine Konstante im Prolog der Funktion zu ändern.
Wasting Stapelspeicher ist billig, ist es wahrscheinlich der heißeste Teil des Cache-Speichers ist.
Meine Vermutung ist, dass Apple glaubt jeder nur XCode nutzt (gcc), die für Sie den Stapel ausgerichtet ist. So den Stapel erfordert ausgerichtet werden, damit der Kernel nicht, ist nur eine Mikro-Optimierung.
Während ich kann nicht wirklich Ihre Frage beantworten, warum Sie die Handbücher auf der folgenden Website finden können nützlich:
http://www.agner.org/optimize/
Im Hinblick auf das ABI, einen Blick vor allem auf:
http://www.agner.org/optimize/calling_conventions.pdf
Hoffe, das ist nützlich.
Hmm, nicht OS X ABI tun auch lustig RISC wie Dinge wie kleine Strukturen in den Registern vorbei?
Damit verweist auf die Konsistenz mit anderen Plattformen Theorie.
Kommen Sie, daran zu denken, die FreeBSD syscall api richtet auch 64-Bit-Werte. (Wie zum Beispiel lseek und mmap)
Um die Kohärenz im Kernel zu halten. Dies ermöglicht es dem gleichen Kernel auf mehreren Architekturen ohne modicfication gestartet werden.
Nicht sicher, warum niemand die Möglichkeit einer einfachen Transport von älteren PowerPC-basierten Plattform betrachtet hat?
Lesen Sie diese:
Und dann in gezoomt und schließlich das "32-Bit-PowerPC-Funktion Aufrufkonventionen":
"Das ist die Einbettung verfügbar Ausrichtung Modi in dem 32-Bit PowerPC-Umgebung:
Energieausrichtungsmodus wird von den Ausrichtungsregeln durch die verwendete abgeleitet IBM XLC-Compiler für das Betriebssystem AIX. Es ist die Standardeinstellung Ausrichtungsmodus für die PowerPC-Architektur Version von GCC unter AIX verwendet und Mac OS X. Da dieser Modus am ehesten kompatibel sein zwischen PowerPC-Architektur Compiler von verschiedenen Anbietern, ist es typischerweise mit Datenstrukturen verwendet, die zwischen verschiedenen gemeinsam genutzt werden Programme. "
Im Hinblick auf den Legacy-PowerPC-basierten Hintergrund von OSX, Portabilität ist ein wichtiger Aspekt - es diktiert nach der Konvention des ganzen Weg zurück zu AIX der XLC-Compiler. Wenn Sie in Bezug auf die Notwendigkeit, denken alle sicherstellen, dass die Tools und Anwendungen zusammenarbeiten, um mit minimalem Aufwand, ich denke, es ist wichtig, auf das gleiche Erbe zu halten ABI so weit wie möglich.
Das gibt die Philosophie, und das Lesen ist weiter die Regel explizit erwähnt ( „Prolog und Epilog“):
Die aufgerufene Funktion ist verantwortlich für die Zuteilung sein eigener Stapelrahmen, um sicherzustellen, 16-Byte-Ausrichtung in dem bewahren Stapel. Dieser Vorgang wird durch einen Abschnitt des Codes erreicht genannt prolog, der die Compiler Stellen vor dem Körper der Subroutine. Nach dem Körper des Unterprogramms legt der Compiler einen Epilog zu Wiederherstellen der Prozessor in den Zustand vor dem Unterprogramm war nennen.
