Warum ist der Mac-ABI erfordert 16-byte-stack-Ausrichtung für x86-32?

Kann ich verstehen, diese Anforderung für die alten PPC-RISC-Systemen und auch für x86-64, sondern für die alte erprobte und wahre x86? In diesem Fall wird der Stapel ausgerichtet werden muss auf 4-byte-Grenzen nur. Ja, einige der MMX/SSE Anweisungen erforderlich 16byte Ausrichtungen, aber wenn, dass ist eine Anforderung von den angerufenen, dann sollte Sie für die Zuordnungen korrekt sind. Warum Last jeder Anrufer mit dieser zusätzlichen Anforderung? Dies kann tatsächlich dazu führen, dass einige Tropfen in die Leistung, da jeder call-site verwalten müssen diese Anforderung. Bin ich etwas fehlt?

Update: Nach einigen weiteren Untersuchung dieser und einiger Beratung mit einigen internen Kolleginnen und Kollegen, ich habe einige Theorien darüber:

  1. Konsistenz zwischen der PPC -, x86-und x64-version des OS
  2. Es scheint, dass die GCC-codegen jetzt konsequent wird eine sub esp,xxx und dann "mov"s die Daten auf den Stapel, anstatt einfach ein "push" - Anweisung. Dies könnte sogar schneller sein auf einige hardware.
  3. Während dies erschwert die call sites ein wenig, es gibt sehr wenig zusätzlichen overhead bei Verwendung des Standard "cdecl" - convention, wo der Aufrufer bereinigt den stack.

Habe ich ein Problem mit dem letzten Punkt, ist, dass für den Aufruf-Konventionen, die sich auf die aufgerufene Reinigung der stack, die oben genannten Anforderungen wirklich "uglifies" die codegen. Zum Beispiel, was manche compiler beschlossen, die eine schnellere register-basierten Aufruf Stil für seine eigene interne Verwendung (ie-code, der ist nicht dazu da, genannt zu werden, die aus anderen Sprachen oder Quellen)? Diese stack-alignment-Sache verneinen könnte, einige der performance-Gewinne erreicht durch die übergabe einiger Parameter in Registern.

Update: bisher die einzige wirkliche Antworten wurden Konsistenz, aber für mich ist das eine etwas zu einfache Antwort. Ich habe über 20 Jahre Erfahrung mit der x86-Architektur, und wenn die Konsistenz, nicht die Leistung, oder etwas anderes konkretes ist, ist wirklich der Grund, dann ich respektvoll vorschlagen, dass ist ein bisschen naiv für die Entwickler, um es erfordern. Sie ignorieren fast drei Jahrzehnten tools und support. Vor allem, wenn Sie erwarten, dass Anbieter von tools, um schnell und einfach an Ihre Werkzeuge für Ihre Plattform (vielleicht auch nicht... es ist Apple...), ohne zu springen durch mehrere scheinbar unnötige Reifen.

Gebe ich dieses Thema an einem anderen Tag oder so schließen Sie es dann...

Verwandte

  • Nicht-API. ABI (Application Binär - Schnittstelle.
InformationsquelleAutor Allen Bauer | 2009-03-04
  1. 29

    Aus der "Intel®64 and IA-32 Architectures Optimization Reference Manual", Kapitel 4.4.2:

    "Für die beste Leistung, die Streaming-SIMD-Erweiterungen und Streaming SIMD Extensions 2 erfordern es, dass Ihre Speicher-Operanden ausgerichtet werden, um 16-byte-Grenzen. Nicht ausgerichtete Daten kann zu erheblichen Leistungseinbußen im Vergleich zu Daten ausgerichtet."

    Anhang D:

    "Es ist wichtig, um sicherzustellen, dass der stack frame ist ausgerichtet auf eine 16-byte-Grenze, die auf Funktion Eintrag zu halten, local __m128 Daten, Parameter und XMM register spill Standorte ausgerichtet, während ein Funktions-Aufruf."

    http://www.intel.com/Assets/PDF/manual/248966.pdf

    InformationsquelleAutor rob mayoff
  2. 6

    Ich bin mir nicht sicher, wie ich haben keine erste-hand-Beweis, aber ich glaube, der Grund ist SSE. SSW ist viel schneller, wenn Ihre Puffer sind bereits ausgerichtet auf eine 16-Byte-Grenze (movps vs movups), und x86 hat mindestens sse2-Unterstützung für mac os x. Es kann gesorgt werden, indem der Benutzer der Anwendung, aber der Preis ist ziemlich bedeutend. Wenn die Gesamtkosten für die es Pflicht in der ABI ist nicht allzu bedeutend, es kann es Wert. SSE wird durchaus genutzt um sich greifenden in mac os X: beschleunigen, Rahmen, etc...

    • Das ist der beste Grund, warum ich mit oben kommen kann als gut... aber die Voraussetzung ist, dass der Stapel ausgerichtet ist, bevor dem Aufruf. Sobald der angerufene ist in der Steuerung, der stack ist nicht mehr ausgerichtet! (die Rückkehr-Adresse wird dem stack).
    • Es spielt keine Rolle, so viel, dass der stack-pointer ist nicht ausgerichtet an diesem Punkt, weil Sie wollen, dass die Argumente, die ausgerichtet werden, im Speicher. Also mit dem typischen stack-Frames, Sie sind garantiert, dass Sie 16-byte-ausgerichtet, bei 8(%ebp), die Ihre Argumente beginnen.
    InformationsquelleAutor David Cournapeau
  3. 5

    Ist, glaube ich, zu halten, ihn mit der x86-64-ABI.

    • Das macht Sinn... bis zu einem Punkt. Was ist der Wert in diesem, wirklich? Nur Werkzeug Macher wirklich über diese Dinge als die meisten Entwickler verlassen sich einfach auf das Werkzeug, um "das richtige zu tun."
    • Vielleicht aufgrund der (relativ) kurzen Leben x86-32 ist wahrscheinlich auf dem Mac?
    InformationsquelleAutor Andrew Grant
  4. 3

    Beachten Sie zunächst, dass der 16-Byte-alignment ist eine Ausnahme eingeführt von Apple, um die System-V-IA-32-ABI.

    Die stack-Ausrichtung ist nur nötig, wenn der aufrufende system funktioniert, denn viele system-Bibliotheken verwenden, SSE oder Altivec-Erweiterungen, bei denen der 16-Byte-Ausrichtung. Ich fand einen expliziten Verweis in der libgmalloc MANN Seite.

    Können Sie perfekt mit Ihren stack-frame, wie Sie wollen, aber wenn Sie versuchen, rufen eine system-Funktion mit einem Schiefen Stapel, werden Sie am Ende mit einem misaligned_stack_error Nachricht.

    Edit:
    Für den Datensatz, können Sie loswerden der alignment-Probleme beim kompilieren mit GCC mithilfe der mstack-neu auszurichten option.

    • Das problem ist, dass der compiler nicht wirklich wissen, dass ein Aufruf einer Systemfunktion oder nicht. Dies bedeutet, dass die einzige "sichere" Sache zu tun ist, um sicherzustellen, die Stapel ausgerichtet bleibt während der gesamten Aufrufkette. Wir nutzen bereits diese Tatsache beim Umgang mit hand-codiert low-level-assembler-Funktionen, die bekannt sind, um nie am Ende aufrufen system-Funktionen.
    • Ach noch was, es ist irgendwie schwer zu "kompilieren mit GCC", da wir in den Prozess der Modifizierung unserer bestehenden Delphi compiler target-Mac... GCC ist nicht beteiligt, da haben wir unser eigenes frontend und code-generator/backend, das ist der Grund, warum dies ist ein Problem.
    InformationsquelleAutor Laurent Etiemble
  5. 2

    Dies ist ein Effizienz-Problem.

    Sicherstellen, dass der Stapel 16-byte-ausgerichtet, in jeder Funktion verwendet die neue SSE-Instruktionen bringt eine Menge overhead mit diesen Anweisungen, eine effektive Senkung der Leistung.

    Auf der anderen Seite, halten die Stapel 16-byte-ausgerichtet auf alle Zeiten sichergestellt, dass Sie verwenden können, SSE-Anweisungen frei mit keine Leistungseinbußen. Es gibt keine Kosten, um diese Kosten (gemessen in der Anleitung zumindest). Es nur um das ändern einer Konstanten im Prolog der Funktion.

    Verschwenden stack-Speicher ist Billig, es ist wohl der heißeste Teil des cache.

    • Ich finde, dass dies eine sehr seichte Erklärung. Warum jedes - Funktion in der call-Kette haben, diese Arbeit zu tun auf der off-chance, dass ein SSE-Instruktion kann verwendet werden? Wenn dieser "Aufwand" ist keine große Sache, dann ist es "keine große Sache", es zu tun an dem Punkt, wo die SSE-Anweisungen verwendet werden! ich nicht verlangen, meine Nachbarn halten meine Haus sauber.
    • Ihre Schlussfolgerung ist falsch. Beachten Sie den Unterschied zwischen machen und zu halten. Es gibt keine arbeiten, die mit der Beibehaltung der stack 16 byte ausgerichtet. Diese einfach bedeutet, dass eine Konstante, in der Prolog, um zu gewährleisten, dass der Stapel ausgerichtet ist. Ich aktualisiert meine ursprüngliche Antwort, unterstreichen dies. OTOH, so dass der Stapel 16-byte-ausgerichtet, beinhaltet die Arbeit und die Kosten, gemessen in Instruktionen.
    • Das ist nur, wenn der compiler code-generator funktioniert wie GCC. Die Welt ist weit mehr als der GCC. Wenn der compiler reserviert stack Platz für alle einheimischen und alle Parameter für alle Funktionen die aktuelle Funktion aufruft, gültig ist. Aber viele Compiler kann nicht funktionieren auf diese Weise, und in der Tat versucht, um machen Sie funktionieren auf diese Weise vielleicht zu teuer. Die andere Sache ist, dass nicht alle SSE-Anweisungen Ausrichtung erfordern, nur die MOVxxA Anweisungen tun. So ist dann auch die Teilmenge der möglichen Anweisungen, die das system-tuning ist relativ klein. Eine app kann nie verwenden, SSE, direkt oder indirekt.
    • Die Kosten-Analyse ist die gleiche, ob stack-Speicher für alle einheimischen vorbehalten ist, die durch die Prolog oder nicht. Wenn der Stapelspeicher reserviert sub - $xx, %esp ist der Weg, es zu tun. Halten Sie den Stapel 16-byte-ausgerichtet, bedeutet " xx " ist ein multuple 16. Alle compiler tun muss, ist zu Runden. Vielleicht könnten Sie ein Beispiel geben, wo es weh tut?
    InformationsquelleAutor user239558
  6. 2

    Meine Vermutung ist, dass Apple glaubt einfach jeder nutzt XCode (gcc), die richtet den Stapel für Sie. So dass der Stapel ausgerichtet werden, damit der kernel nicht haben, ist nur eine Mikro-Optimierung.

    • Hinweis: Xcode nutzt llvm-gcc
    InformationsquelleAutor Mike
  7. 1

    Während ich kann nicht wirklich die Antwort auf Ihre Frage, WARUM, finden Sie die Handbücher unter der folgenden Website hilfreich sein:

    http://www.agner.org/optimize/

    Bezüglich der ABI, haben einen Blick besonders an:

    http://www.agner.org/optimize/calling_conventions.pdf

    Hoffe, das ist nützlich.

    InformationsquelleAutor PhiS
  8. 1

    Hmm, nicht OS X ABI auch lustig RISC wie Dinge wie, vorbei an kleinen structs in Registern?

    So, dass die Punkte, um die Konsistenz mit anderen Plattformen Theorie.

    Kommen Sie, daran zu denken, die FreeBSD-syscall-api richtet außerdem 64-bit-Werte. (wie z.B. lseek und mmap)

    InformationsquelleAutor Marco van de Voort
  9. 0

    Um die Konsistenz zu wahren, der im kernel. Dies ermöglicht es der gleiche kernel gebootet werden, die auf mehreren Architekturen ohne modicfication.

    • Das ist die einzige Sache, die scheint zu sein, was die Leute sagen, jedoch für höhere level-Sprachen, das ist ein detail, das ist (sein sollte) versteckt. Jede kompilierte x86-32 ObjC, C, oder C++ - Anwendung würde sich nicht sorgen, denn dies ist eine undurchsichtige detail.
    • Ein kernel muss kompatibel sein mit dem Aufruf-stack der user-Prozesse, denn es müssen gelegentlich für die Arbeit Raum zum verarbeiten bestimmter Systemaufrufe oder interrupts.
    • Es scheint nicht zu verletzen und die Windows-und Linux-Kernel nicht angepasst werden. Was ist so besonderes daran, das MacOS auf x86?
    InformationsquelleAutor PixelSmack
  10. 0

    Nicht sicher, warum, niemand als die Möglichkeit der einfachen Portabilität von älteren PowerPC-basierten Plattform?

    Lesen:

    http://developer.apple.com/library/mac/#documentation/DeveloperTools/Conceptual/LowLevelABI/100-32-bit_PowerPC_Function_Calling_Conventions/32bitPowerPC.html#//apple_ref/doc/uid/TP40002438-SW20

    Und dann gezoomt "32-bit-PowerPC-Funktion Calling Conventions" und schließlich:

    "Dies sind die Einbettung Ausrichtung Modi verfügbar im 32-bit
    PowerPC-Umgebung:

    Macht alignment-Modus ist abgeleitet von der Ausrichtung Regeln die
    IBM XLC-compiler für das Betriebssystem AIX. Es ist der Standard
    Ausrichtung-Modus für die PowerPC-Architektur-version von GCC auf AIX verwendet
    und Mac OS X. Da dieser Modus ist am ehesten kompatibel zu sein
    zwischen PowerPC-Architektur von Compilern von verschiedenen Herstellern, es
    in der Regel verwendet mit einer Datenstruktur, geteilt zwischen den verschiedenen
    Programme".

    Im Blick auf den älteren PowerPC-basierten hintergrund von OSX, Portabilität ist ein wichtiger Aspekt - es diktiert, mit der Konvention den ganzen Weg zurück nach AIX XLC compiler. Wenn Sie denken, in Bezug auf die Notwendigkeit, sicherzustellen, dass alle tools und Anwendungen zusammen arbeiten, mit minimalen Nacharbeiten, ich denke, es ist wichtig, zu bleiben, um die gleichen legacy-ABI so weit wie möglich.

    Gibt die Philosophie, und Lesen weiter in der Regel explizit erwähnt ("Prolog und Epilog"):

    Die aufgerufene Funktion ist verantwortlich für die Verteilung
    seinen eigenen stack-frame, so dass Sie sicher zu bewahren, 16-byte-Ausrichtung in der
    stack. Diese operation wird durchgeführt, indem ein Abschnitt von code genannt
    prolog, das setzt der compiler an, bevor der Körper der subroutine.
    Nachdem der Körper der subroutine, setzt der compiler das Nachwort zu
    wiederherstellen der Prozessor in den Zustand vor dem Unterprogramm
    nennen.

    InformationsquelleAutor Peter Teoh
Schreibe einen Kommentar