Was könnte C/C++ “verlieren”, wenn sie eine Standard-ABI definieren?

Lesezeit: 9 Minuten

Der Titel sagt alles. Ich spreche speziell von C/C++, weil beide dies als “Implementierungsproblem” betrachten. Ich denke, die Definition einer Standardschnittstelle kann den Aufbau eines Modulsystems darauf und viele andere gute Dinge erleichtern.
Was könnte C/C++ “verlieren”, wenn sie eine Standard-ABI definieren?

  • Wofür steht ABI? Scheint ein bekanntes Akronym zu sein, aber ich konnte keine Definition finden.

    – Dirk Vollmar

    17. Januar 2010 um 23:42 Uhr


  • ABI ist eine Anwendungsbinärschnittstelle. en.wikipedia.org/wiki/Application_binary_interface

    – Amok

    17. Januar 2010 um 23:43 Uhr

  • @Martin: Nein, C hat keine Standard-ABI für jedes System. Es ist ziemlich umgekehrt. Die meisten, aber nicht alle Systeme haben eine C ABI definiert. Die ISO SC22 WG14 (auch bekannt als das C-Komitee) definiert sie nicht; die Plattform-“Eigentümer” definieren sie.

    – MSalter

    18. Januar 2010 um 8:11 Uhr

  • @MSalters: Das wollte ich sagen. Der Compiler definiert es nicht, der Compiler erbt es von der Standardbibliothek (die möglicherweise nicht einmal in C geschrieben ist). Aber der Compiler muss Code generieren, der binärkompatibel ist (und somit der ABI entspricht, die von der Standardbibliothek verwendet wird). Mir war nicht bewusst, dass es von der Plattform definiert wurde, aber das macht Sinn, da die Plattform (ich nehme an, Hardware/Betriebssystem) dann bestimmt, wie die Standardbibliothek erstellt wird. Zusammenfassend habe ich versucht zu sagen (aber schlecht), dass der Compiler das von der Plattform definierte C ABI implementiert.

    – Martin York

    18. Januar 2010 um 8:24 Uhr


  • @MArtin: Die “Standardbibliothek” ist Teil der “C-Implementierung” – der ISO-Standard beschreibt die Kombination aus Präprozessor, Compiler, Linker, Bibliotheken und anderen Teilen, die sich zusammen wie vorgeschrieben verhalten. Daher kann der Compiler Code generieren, der der Standardbibliothek entspricht, die zusammen mit diesem Compiler installiert wird. Die zwischen ihnen geteilte ABI ist daher eine produktspezifische ABI. Dies ist nicht nur Theorie: Die Standardbibliothek von MSVC9 ist spezifisch für den MSVC9-Compiler (aufgrund von Pufferüberlaufschutzprüfungen).

    – MSalter

    18. Januar 2010 um 9:19 Uhr

Was konnte CC verlieren wenn sie eine Standard ABI definieren
dmckee — Ex-Moderator-Kätzchen

Die Freiheit, Dinge auf jedem Prozessor auf die natürlichste Weise zu implementieren.

Ich stelle mir vor, dass insbesondere c konforme Implementierungen auf mehr unterschiedlichen Architekturen hat als jede andere Sprache. Das Festhalten an einem ABI, das für die derzeit gängigen Allzweck-High-End-CPUs optimiert ist, würde auf einigen der seltsameren Maschinen da draußen unnatürliche Verzerrungen erfordern.

  • Sehr einverstanden. Auf vielen Plattformen möchten Sie Argumente aus Gründen der Geschwindigkeit in Registern übergeben, aber Sie möchten nicht alle Register für die Argumentübergabe verwenden. Aber verschiedene Plattformen haben eine unterschiedliche Anzahl von Registern. Einige Plattformen haben überhaupt keine Gleitkommaregister. Jeder völlig allgemeine ABI wäre auf fast jeder Plattform suboptimal.

    – Stefan Kanon

    17. Januar 2010 um 23:32 Uhr

  • Einer der Gründe, warum C so beliebt wurde, war, dass es keine Standard-ABI spezifizierte (IIRC, Pascal tat es). Daher konnten Compiler-Autoren tun, was am besten funktionierte. Anfangs taten alle ziemlich dasselbe in Bezug auf das Stack-Framing, aber später begannen sie für Architekturen wie DSPs damit, Wege zu spezifizieren, um Funktionsargumente in Register zu packen, wodurch die Anzahl der für einen Funktionsaufruf erforderlichen Anweisungen und Speichertransaktionen erheblich reduziert wurde.

    – Mike DeSimone

    17. Januar 2010 um 23:44 Uhr

  • Ich erinnere mich an eine Architektur, die eine 32-Register-Datei hatte, die für den Programmierer sichtbar war, sie aber in Hardware als 512-Register-Block mit einem Schiebefenster implementierte. r0-r7 waren Parameter, die an eine aufgerufene Funktion übergeben wurden, r8-r15 waren lokale Funktionen, r16-r23 waren Parameter, die vom Aufrufer der Funktion übergeben wurden, und r24-r31 waren globale Parameter, einschließlich des Stapelzeigers. r24-31 würde immer auf dieselbe Stelle zeigen, aber die anderen wurden durch ein Fenster abgebildet, das mit einem Funktionsaufruf 16 Register nach unten rutschte (das r0-7 des Aufrufers auf r16-r23 des Angerufenen abbildete) und dann bei der Rückkehr 16 zurückrutschte .

    – Mike DeSimone

    17. Januar 2010 um 23:48 Uhr

  • @Mike: Das klingt sehr nach SPARC, aber verschiedene Generationen hatten unterschiedliche Mengen an HW-Registern, bevor sie in den Arbeitsspeicher übergingen.

    – MSalter

    18. Januar 2010 um 8:13 Uhr

  • @ Hibou57: Diese Frage erkennt diese Tatsache nicht an.

    – Ben Voigt

    17. Mai 2013 um 19:13 Uhr

Abwärtskompatibilität auf jeder Plattform außer derjenigen, deren ABI gewählt wurde.

  • Wer auch immer dies standardisiert, könnte sich alternativ weigern, eine vorhandene ABI zu wählen (vermutlich, weil sich niemand auf die eines Konkurrenten einigen könnte), und dann hätte niemand Abwärtskompatibilität.

    – David Thornley

    17. Januar 2010 um 23:33 Uhr

  • Und dann würde sich niemand an die Norm halten.

    – Stefan Kanon

    17. Januar 2010 um 23:38 Uhr


  • Wir haben jetzt keine Abwärtskompatibilität. Jedes Mal, wenn ein Compiler aktualisiert wird, müssen Sie möglicherweise alle Ihre Bibliotheken neu kompilieren, um der neuen ABI zu entsprechen, die er definiert.

    – Martin York

    18. Januar 2010 um 1:10 Uhr

  • @Stephen: GCC hat es in der vorherigen Version dreimal gemacht. 2.9x -> 3.0 (Pause: Neues ABI) 3.0 -> 3.1 (Pause Bug Fix) 3.1 -> 3.2 (Pause Etwas anderes)

    – Martin York

    18. Januar 2010 um 2:24 Uhr

  • Es mag Probleme in C++ mit GCC gegeben haben, aber ich kann mich nicht an Probleme mit C erinnern.

    – Jonathan Leffler

    18. Januar 2010 um 5:15 Uhr

Im Grunde hat jeder übersehen, dass einer der C++14-Vorschläge tatsächlich eine Standard-ABI definiert hat. Es war eine Standard-ABI speziell für Bibliotheken, die eine Teilmenge von C++ verwendeten. Sie definieren bestimmte Abschnitte von „ABI“-Code (wie einen Namensraum) und dieser muss der Teilmenge entsprechen.

Darüber hinaus wurde es von DEM Herb Stutter geschrieben, C++-Experte und Autor der Buchreihe „Exceptional C++“.

Der Vorschlag geht auf viele Gründe ein, warum ein tragbares ABI schwierig ist, sowie auf neuartige Lösungen.

https://isocpp.org/blog/2014/05/n4028

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4028.pdf

Beachten Sie, dass er eine „Zielplattform“ als eine Kombination aus CPU-Architektur (x64, x86, ARM usw.), Betriebssystem und Bitness (32/64) definiert.

Das Ziel hier ist also, dass C++-Code (Visual Studio) mit anderem C++-Code (GCC, älteres Visual Studio usw.) auf derselben Plattform kommunizieren kann. Es ist nicht das Ziel einer universellen ABI, mit der Handybibliotheken auf Ihrem Windows-Computer ausgeführt werden können.

Dieser Vorschlag wurde in C++14 NICHT ratifiziert, aberwurde es zur weiteren Diskussion/Iteration in die „Evolution“-Phase von C++17 verschoben.

https://www.ibm.com/developerworks/community/blogs/5894415f-be62-4bc0-81c5-3956e82276f3/entry/c_14_is_ratified_the_view_from_the_june_2014_c_standard_meeting?lang=en

Ab Januar 2017 drücke ich also weiterhin die Daumen.

  • Angesichts der Tatsache, dass die überwiegende Mehrheit der Plattformen, auf denen C und C++ verwendet werden, bis auf eine kleine Anzahl von “Parametern” identisch sind, wäre es sinnvoll, Merkmale zu erkennen, die identifizierbaren Untergruppen von Plattformen gemeinsam sind. Mit dem Komitee zu fliegen sehe ich allerdings nicht, auch wenn es viele Probleme lösen würde.

    – Superkatze

    9. Januar 2017 um 23:10 Uhr


  • 1988 gab es keinen Standard, aber Compiler-Autoren versuchten, miteinander kompatibel zu sein, selbst wenn kein Standard dies erforderte. Wenn der Standard Konventionen anerkannt hätte, aber auch erkannt hätte, dass sie die Optimierung beeinträchtigen würden, hätte er neue Wege einführen können, um dieselbe Semantik zu erreichen, ohne die Optimierung zu beeinträchtigen, und dann die alten verworfen. Wenn die Sprache außerdem einen Typ “32 Bit unsigned int gespeichert als vier Bytes Big-Endian” sowie Varianten anderer Größen, Vorzeichen, Endianness usw. enthalten hätte, hätte dies die Sprache auf Maschinen nützlicher gemacht …

    – Superkatze

    9. Januar 2017 um 23:17 Uhr

  • … mit seltsamen Int-Größen, da solche Maschinen Code ausführen könnten, der diese Typen bei Bedarf effizienter verwendet, als Code ausführen könnten, der Oktett-basierte Daten mit anderen Systemen austauschen muss und das Fehlen solcher Typen umgehen muss.

    – Superkatze

    9. Januar 2017 um 23:18 Uhr

  • Ich würde gerne hören, ob es ab Mai 2017 ein Update zu diesem Thema gibt. Wurde es für C++17 ratifiziert?

    – Adirio

    4. Mai 2017 um 9:43 Uhr

1645911014 0 Was konnte CC verlieren wenn sie eine Standard ABI definieren
Martin York

Anstelle eines generischen ABI für alle Plattformen (was fatal wäre, da es nur für nur eine Plattform optimal wäre). Das Komitee des Standards könnte sagen, dass jede Plattform einem bestimmten ABI entspricht.

Aber: Wer definiert es (der erste Compiler durch die Tür?). In diesem Fall erhalten sie einen übermäßigen Wettbewerbsvorteil. Oder ein Komitee nach 5 Jahren Compiler (was eine weitere schreckliche Idee wäre).

Außerdem gibt es dem Compiler keinen Spielraum, um weiter nach neuen Optimierungsstrategien zu forschen, Sie würden mit den Tricks stecken bleiben, die zu dem Zeitpunkt verfügbar waren, an dem der Standard definiert wurde.

1645911015 88 Was konnte CC verlieren wenn sie eine Standard ABI definieren
Basile Starynkevitch

Die Sprachspezifikationen C (oder C++) definieren die Quellsprache. Sie kümmern sich nicht um den Prozessor, auf dem es läuft (AC-Programm könnte sogar von einem menschlichen Sklaven interpretiert werden, aber das wäre unethisch und nicht kosteneffektiv).

Der ABI ist per Definition etwas über das Zielsystem. Es bezieht sich auf den Prozessor und das System (und die bestehenden Bibliotheken, die der ABI folgen).

In der Vergangenheit kam es vor, dass einige Prozessoren proprietäre (dh nicht offengelegte) Spezifikationen hatten (sogar ihr Maschinenbefehlssatz war nicht öffentlich), und sie hatten eine nicht öffentliche ABI, auf die ein Compiler folgte (der mehr oder weniger den Sprachstandard respektierte ).

Das Definieren einer Programmiersprache erfordert nicht die gleichen Fähigkeiten wie das Definieren der ABI.

Sie könnten sogar eine neuere ABI für einen vorhandenen Prozessor definieren, aber das erfordert viel Arbeit (den Compiler patchen, alles neu kompilieren, einschließlich der C- und C++-Standardbibliotheken und aller Dienstprogramme und Bibliotheken, die Sie benötigen) und ist daher im Allgemeinen nutzlos.

1645911016 138 Was konnte CC verlieren wenn sie eine Standard ABI definieren
Justin Smith

Die Ausführungsgeschwindigkeit würde auf den meisten Plattformen drastisch darunter leiden. So sehr, dass es wahrscheinlich nicht mehr sinnvoll wäre, die C-Sprache für eine Reihe von eingebetteten Plattformen zu verwenden. Das Standardisierungsgremium könnte für eine Kartellklage haftbar gemacht werden, die von den Herstellern der verschiedenen Chips angestrengt wird, die nicht mit dem ABI kompatibel sind.

Was konnte CC verlieren wenn sie eine Standard ABI definieren
Zifre

Nun, es gäbe nicht eine Standard-ABI, sondern ungefähr 1000. Sie würden eine für jede Kombination aus Betriebssystem und Prozessorarchitektur benötigen.

Zunächst würde nichts verloren gehen. Aber irgendwann würde jemand einen schrecklichen Fehler finden und ihn entweder beheben, den ABI brechen, oder ihn verlassen und Probleme verursachen.

Ich denke, dass die Situation im Moment in Ordnung ist. Jedes Betriebssystem kann eine ABI für sich selbst definieren (und das tun sie), was sinnvoll ist. Es sollte die Aufgabe des Betriebssystems sein, seine ABI zu definieren, nicht der C/C++-Standard.

  • Oder der Entwickler für diejenigen, die Code entwickeln, der ohne Betriebssystem läuft.

    – Justin Smith

    17. Januar 2010 um 23:49 Uhr

868410cookie-checkWas könnte C/C++ “verlieren”, wenn sie eine Standard-ABI definieren?

This website is using cookies to improve the user-friendliness. You agree by using the website further.

Privacy policy