DE102015002582A1 - Architekturübergreifendes Kompatibilitätsmodul, um zuzulassen, dass ein Codemodul einer Architektur ein Bibliotheksmodul einer anderen Architektur verwendet - Google Patents

Architekturübergreifendes Kompatibilitätsmodul, um zuzulassen, dass ein Codemodul einer Architektur ein Bibliotheksmodul einer anderen Architektur verwendet Download PDF

Info

Publication number
DE102015002582A1
DE102015002582A1 DE102015002582.1A DE102015002582A DE102015002582A1 DE 102015002582 A1 DE102015002582 A1 DE 102015002582A1 DE 102015002582 A DE102015002582 A DE 102015002582A DE 102015002582 A1 DE102015002582 A1 DE 102015002582A1
Authority
DE
Germany
Prior art keywords
module
bit
architecture
code
library
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
DE102015002582.1A
Other languages
English (en)
Inventor
Niranjan Hasabnis
Suresh Srinivas
Jayaram Bobba
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Intel Corp
Original Assignee
Intel Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Intel Corp filed Critical Intel Corp
Publication of DE102015002582A1 publication Critical patent/DE102015002582A1/de
Pending legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/40—Transformation of program code
    • G06F8/41—Compilation
    • G06F8/43—Checking; Contextual analysis
    • G06F8/433—Dependency analysis; Data or control flow analysis
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/30003—Arrangements for executing specific machine instructions
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/3017—Runtime instruction translation, e.g. macros
    • G06F9/30174—Runtime instruction translation, e.g. macros for non-native instruction set, e.g. Javabyte, legacy code
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/445—Program loading or initiating
    • G06F9/44521—Dynamic linking or loading; Link editing at or after load time, e.g. Java class loading
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/40—Transformation of program code
    • G06F8/52—Binary to binary
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/38—Concurrent instruction execution, e.g. pipeline or look ahead
    • G06F9/3867—Concurrent instruction execution, e.g. pipeline or look ahead using instruction pipelines
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45504—Abstract machines for programme code execution, e.g. Java virtual machine [JVM], interpreters, emulators
    • G06F9/45516—Runtime code conversion or optimisation
    • G06F9/4552—Involving translation to a different instruction set architecture, e.g. just-in-time translation in a JVM
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/54—Interprogram communication
    • G06F9/545—Interprogram communication where tasks reside in different layers, e.g. user- and kernel-space

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Stored Programmes (AREA)

Abstract

Ein architekturübergreifendes Kompatibilitätsgerät eines Aspekts umfasst ein Kontrollflusstransferempfangsmodul, um eine erste Prozeduraufrufoperation, die für ein Bibliotheksmodul erster Architektur bestimmt ist, von einem Codemodul erster Architektur zu empfangen. Die erste Prozeduraufrufoperation bezieht eine erste Vielzahl an Eingabeparametern ein. Ein Binärschnittstellenänderungsmodul (ABI-Änderungsmodul) ist mit dem Kontrollflusstransferempfangsmodul gekoppelt. Das ABI-Änderungsmodul macht ABI-Änderungen, um die erste Prozeduraufrufoperation, die die erste Vielzahl an Eingabeparametern umfasst, in eine entsprechende zweite Prozeduraufrufoperation, die eine zweite Vielzahl an Eingabeparametern umfasst, zu konvertieren. Die zweite Prozeduraufrufoperation ist mit einem Bibliotheksmodul zweiter Architektur kompatibel. Ein Kontrollflusstransferausgabemodul ist mit dem ABI-Änderungsmodul gekoppelt. Das Kontrollflusstransferausgabemodul stellt die zweite Prozeduraufrufoperation für das Bibliotheksmodul zweiter Architektur bereit.

Description

  • HINTERGRUND
  • Fachgebiet
  • Hierin beschriebene Ausführungsformen beziehen sich im Allgemeinen auf die Ausführung von Code auf elektronischen Vorrichtungen. Im Speziellen beziehen sich hierin beschriebene Ausführungsformen auf die Ausführung von Code verschiedener Architekturen auf elektronischen Vorrichtungen.
  • Hintergrundinformation
  • Bis vor kurzem basierten die meisten Smartphones, Mobiltelefone, Tabletcomputer und dergleichen auf 32-Bit-Architekturen. Sie hatten 32-Bit-Architekturprozessoren und 32-Bit-Betriebssysteme. Es wurde eine Vielzahl an 32-Bit-Code für diese 32-Bit-Architekturen geschrieben. Beispielsweise wurden zahlreiche mobile Applikationen für diese Vorrichtungen geschrieben. Es wurden auch 32-Bit-Bibliotheken für diese 32-Bit-Architekturen geschrieben.
  • Neuerdings wurden Smartphones mit 64-Bit-Architekturen verfügbar. Diese 64-Bit-Architekturen basieren auf 64-Bit-Architekturprozessoren und 64-Bit-Betriebssystemen. Beispielsweise wurde kürzlich das iPhone 5S von Apple Corporation verfügbar. Das iPhone 5S umfasst einen A7-Prozessorchip mit einer 64-Bit-Architektur und einem 64-Bit-Betriebssystem, bekannt als iOS 7. Andere Smartphones mit 64-Bit-Architektur wurden ebenfalls angekündigt und/oder sind in Entwicklung.
  • Zumindest im Anfangsstadium des Einsatzes dieser Smartphones mit 64-Bit-Architektur wird es wahrscheinlich wünschenswert sein, Rückwärtskompatibilität zu bieten, damit bereits entwickelter 32-Bit-Code auf diesen Smartphones ausgeführt werden kann. Das wird es der großen Vielzahl an bestehenden 32-Bit-Mobilapplikationen und anderem 32-Bit-Code ermöglichen, weiterhin benutzt zu werden.
  • Das iPhone 5S und iOS 7 bieten eine solche Rückwärtskompatibilität. Sie sind in der Lage, sowohl 32-Bit-Code als auch 64-Bit-Code auszuführen. Der 32-Bit-Code ist auch in der Lage, 32-Bit-Bibliotheken zu nützen.
  • KURZE BESCHREIBUNG DER ZEICHNUNGEN
  • Die Erfindung kann am besten verstanden werden, wenn auf die folgende Beschreibung und begleitenden Zeichnungen verwiesen wird, mit denen die Ausführungsformen veranschaulicht werden. In den Zeichnungen:
  • Ist 1 ein Blockdiagramm einer ersten Ausführungsform eines Computersystems, in dem Ausführungsformen der Erfindung durchgeführt werden können.
  • Ist 2 ein Blockdiagramm einer zweiten Ausführungsform eines Computersystems, in dem Ausführungsformen der Erfindung durchgeführt werden können.
  • Ist 3 ein Blockdiagramm einer dritten Ausführungsform eines Computersystems, in dem Ausführungsformen der Erfindung durchgeführt werden können.
  • Ist 4 ein Blockdiagramm einer vierten Ausführungsform eines Computersystems, in dem Ausführungsformen der Erfindung durchgeführt werden können.
  • Ist 5 ein Blockdiagramm einer Ausführungsform eines architekturübergreifenden Kompatibilitätsmoduls.
  • Ist 6 ein Blockdiagramm einer Ausführungsform eines architekturübergreifenden Kompatibilitätsmoduls, das eine Wrapper-Bibliothek hat.
  • Ist 7 ein Blockflussdiagramm einer Ausführungsform eines Verfahrens zum Abfangen von Kontrollflusstransfers mit einer Wrapper-Bibliothek eines architekturübergreifenden Kompatibilitätsmoduls unter Verwendung von Funktionszwischenschaltung.
  • Ist 8 ein Blockdiagramm eines architekturübergreifenden Kompatibilitätsmoduls, das funktionsfähig ist, eine Laufzeitstruktur eines dynamischen Lademoduls zu verwenden, um zu ermitteln, wann Kompatibilitätsmodi geändert werden sollen.
  • Ist 9A ein Blockdiagramm, das eine Ausführungsform einer In-Order-Pipeline und eine Ausführungsform einer Pipeline zur Registerumbenennung mit Ausgabe/Ausführung in anderer Reihenfolge (out-of-order).
  • Ist 9B ein Blockdiagramm einer Ausführungsform eines Prozessorkerns, umfassend eine Vorverarbeitungseinheit, die mit einer Ausführungsmaschineneinheit gekoppelt ist, und die beide mit einer Speichereinheit gekoppelt sind.
  • Ist 10A ein Blockdiagramm einer Ausführungsform eines einzelnen Prozessorkerns, zusammen mit seiner Verbindung zum Ein-Chip-Verbindungsnetzwerk und mit seiner lokalen Untermenge des Level-2-(L2)-Cache.
  • Ist 10B ein Blockdiagramm einer Ausführungsform einer erweiterten Ansicht eines Teils des Prozessorkerns aus 10A.
  • Ist 11 ein Blockdiagramm einer Ausführungsform eines Prozessors, der mehr als einen Kern, einen integrierten Speichercontroller und integrierte Grafiken haben kann.
  • Ist 12 ein Blockdiagramm einer ersten Ausführungsform einer Computerarchitektur.
  • Ist 13 ein Blockdiagramm einer zweiten Ausführungsform einer Computerarchitektur.
  • Ist 14 ein Blockdiagramm einer dritten Ausführungsform einer Computerarchitektur.
  • Ist 15 ein Blockdiagramm einer Ausführungsform einer Ein-Chip-Architektur.
  • Ist 16 ein Blockdiagramm der Nutzung eines Softwarebefehl-Converters, um binäre Befehle in einem Quellbefehlssatz in binäre Befehle in einem Zielbefehlssatz zu konvertieren, gemäß den Ausführungsformen der Erfindung.
  • GENAUE BESCHREIBUNG DER AUSFÜHRUNGSFORMEN
  • Wie im Abschnitt zum Hintergrund erörtert, ermöglicht das iPhone 5S und iOS 7 Rückwärtskompatibilität. Sowohl 32-Bit-Code als auch 64-Bit-Code können auf dem iPhone 5S ausgeführt werden. Der 32-Bit-Code verwendet eine Gruppe von 32-Bit-Bibliotheken. Ebenso verwendet der 64-Bit-Code eine Gruppe von 64-Bit-Bibliotheken. Ein Nachteil dieses Ansatzes für das Bereitstellen von Rückwärtskompatibilität ist jedoch, dass das iPhone 5S sowohl die 32-Bit- als auch die 64-Bit-Version dieser Bibliotheken umfassen muss. Insbesondere ist eine Gruppe von 32-Bit-Bibliotheken für 32-Bit-Code enthalten, damit verbunden und davon verwendet. Eine andere Gruppe von 64-Bit-Bibliotheken ist für 64-Bit-Code enthalten, damit verbunden und davon verwendet. Das Speichern von sowohl der 32-Bit-Bibliothek als auch der 64-Bit-Bibliothek verbraucht mehr Speicherplatz, als bei der Speicherung einer einzelnen Bibliothek nötig wäre.
  • Hierin offenbart sind architekturübergreifende Kompatibilitätsmodule, die Code (z. B. 32-Bit-Code, Legacy Code, etc.) einer bestimmten Architektur erlauben, Bibliotheken einer anderen Architektur (z. B. 64-Bit-Code, eine neuere Architektur, etc.) zu verwenden. In der folgenden Beschreibung sind zahlreiche spezifische Details dargelegt (z. B. spezifische Architekturprozessoren und Betriebssysteme, Unterschied zwischen neuen und alten Architekturen, Beispiele von architekturübergreifenden Kompatibilitätsmodulen, Prozessorkonfigurationen, Arbeitsabläufe, etc.). Ausführungsformen können jedoch ohne diese spezifischen Details betrieben werden. In anderen Fällen wurden wohlbekannte Schaltungen, Strukturen und Techniken nicht im Detail gezeigt, um zu verhindern, dass das Verständnis der Beschreibung verzerrt wird.
  • 1 ist ein Blockdiagramm einer ersten Ausführungsform eines Computersystems 100, in welchem Ausführungsformen der Erfindung implementiert werden können. In verschiedenen Ausführungsformen kann das Computersystem ein Smartphone, ein Mobiltelefon, einen Personal Digital Assistant (PDA), tragbaren Medienspieler, Handendgerät, einen Tabletcomputer, einen Pad-Computer, einen Laptop, einen Desktop-Computer, Workstation, Videospielekonsole, Set-Top-Box, Server, Netzwerkgerät oder andere elektronische Vorrichtungen, die in der Technik bekannt sind, umfassen. In manchen Ausführungsformen kann das Computersystem ein kleines Handendgerät-Computersystem mit eingeschränkten Speicherressourcen darstellen, wie beispielsweise ein Smartphone, Mobiltelefon, PDA, Tabletcomputer oder Handendgerät, wenngleich der Schutzumfang der Erfindung nicht so eingeschränkt ist.
  • Das Computersystem umfasst eine Ausführungsform von einem Prozessor 102 und eine Ausführungsform von einem Speicher 110. Der Prozessor und der Speicher können durch einen herkömmlichen Kopplungsmechanismus 108 miteinander gekoppelt werden oder anderweitig miteinander kommunizieren (z. B. durch einen oder mehrere Busse, Hubs, Speichercontroller, Chipsatz-Komponenten und dergleichen). Viele verschiedene Kopplungsmechanismen, die auf dem Gebiet der Technik bekannt sind, sind geeignet. Der Speicher kann eines oder mehrere Speichervorrichtungen und/oder eine oder mehrere verschiedene Speicherarten wie sie herkömmlicherweise bei solchen Computersystemen verwendet werden umfassen.
  • In der verdeutlichten Ausführungsform ist der Prozessor ein 64-Bit-Architektur-Prozessor, wenngleich der Schutzumfang der Erfindung nicht so eingeschränkt ist. In manchen Ausführungsformen kann der Prozessor ein Mehrzweckprozessor sein. Alternativ kann der Prozessor ein Spezialprozessor sein. Beispiele geeigneter Spezialprozessoren umfassen, sind aber nicht darauf beschränkt, Kommunikationsprozessoren, Grafikprozessoren, Netzwerkprozessoren, kryptographische Prozessoren, Koprozessoren, eingebettete Prozessoren, digitale Signalprozessoren (DSP) und Controller (z. B. Mikrocontroller), um nur einige Beispiele zu nennen. Der Prozessor kann jeder von verschiedenen CISC-(Complex Instruction Set Computer)-Prozessoren, RISC-(Reduced Instruction Set Computer)-Prozessoren, VLIW-(Very Long Instruction Word)-Prozessoren, Hybride davon, andere Prozessorarten sein oder eine Kombination solcher unterschiedlicher Prozessoren haben (z. B. in verschiedenen Kernen).
  • Wie in manchen Ausführungsformen gezeigt wird, kann der 64-Bit-Architektur-Prozessor 64-Bit-Architektur-Ressourcen 104 haben, die für einen 32-Bit-Architektur-Prozessor nicht verfügbar sind. Zum Beispiel können die 64-Bit-Architektur-Ressourcen fortgeschrittene Architekturressourcen und/oder leistungssteigernde Funktionen umfassen, die im 32-Bit-Prozessor nicht vorhanden sind. Zum Beispiel kann der 64-Bit-Prozessor zusätzliche Architekturregister, verbesserte Binärschnittstellen (ABI), verbesserte Parameterübergabelogik für Prozeduraufruf und dergleichen haben. Zum Beispiel mit IA-32-Architektur verglichen, hat Intel®-64-Architektur eine größere Anzahl an Registern, einen zusätzlichen Gleitkomma-Einzelbefehl, Multiple-Data-(SIMD)-Möglichkeiten, eine 64-Bit-ABI, die Parameterübergabe durch Register anstatt durch Stapelzugriffe zulässt. Diese fortgeschrittenen Architekturressourcen und/oder leistungssteigernden Funktionen können bei einer Leistungssteigerung der Software helfen. Diese Ressourcen oder Funktionen sind einer der Gründe für den zunehmenden Trend hin zum 64-Bit-Computing.
  • Sich wieder auf 1 beziehend umfasst der Speicher 110 viele unterschiedliche Arten an Softwaremodulen. In der veranschaulichten Ausführungsform umfassen die Softwaremodule ein 64-Bit-Betriebssystemmodul 112. Das 64-Bit-Betriebssystemmodul kann Software auf Systemebene umfassen, die mit dem 64-Bit-ABI des Prozessors kompatibel ist. Das 64-Bit-Betriebssystemmodul ist allgemein dafür gestaltet, einige oder alle der 64-Bit-Architekturressourcen 104 des 64-Bit-Prozessors verwenden zu können.
  • Der Speicher umfasst auch eines oder mehrere 32-Bit-Codemodule 116 und optional eines oder mehrere 64-Bit-Codemodule 114. In einigen Ausführungsformen können diese kompilierten und/oder Binärcode umfassen. Beispiele solcher 32-Bit- und 64-Bit-Codemodule umfassen Anwendungsmodule, sind aber nicht darauf eingeschränkt. Im speziellen Fall eines Smartphones oder anderen Mobilgeräts können die Anwendungsmodule mobile Applikationen oder Apps umfassen. In einem Aspekt können das eine oder die mehreren 32-Bit-Codemodule alte oder bestehende Codemodule darstellen, die zuvor für eine vorherige 32-Bit-Architektur geschrieben wurden, obwohl der Schutzrahmen der Erfindung nicht so eingeschränkt ist. In einem anderen Aspekt können das eine oder die mehreren 32-Bit-Codemodule stattdessen neu geschriebene 32-Bit-Codemodule sein. Die 32-Bit-Codemodule können für einen 32-Bit-Architekturprozessor erstellt worden sein.
  • Der Speicher umfasst auch 64-Bit-Bibliotheksmodule 118. In manchen Ausführungsformen, wie durch die gestrichelten Linien dargestellt, kann der Speicher und/oder das Computersystem optional 32-Bit-Bibliotheksmodule 120 umfassen. Alternativ kann in anderen Ausführungsformen, wie durch das „X” durch die 32-Bit-Bibliotheksmodule dargestellt, der Speicher und/oder das Computersystem optional solche 32-Bit-Bibliotheksmodule weglassen, sogar wenn eines oder mehrere 32-Bit-Codemodule im Speicher gespeichert sind und auf dem 64-Bit-Prozessor ausgeführt werden können. Beispiele der 32-Bit- und 64-Bit-Bibliotheksmodule umfassen, sind aber nicht darauf beschränkt, jene für die C-Standard-Bibliothek, Mathematikbibliotheken, Systembibliotheken und dergleichen.
  • Während des Betriebs können sowohl 32-Bit-Code als auch 64-Bit-Code auf dem 64-Bit-Prozessor ausgeführt werden. Beispielsweise können Befehle oder Code von dem 64-Bit-Betriebssystemmodul, von einem oder mehreren 32-Bit-Codemodulen und den 64-Bit-Bibliotheksmodulen auf dem 64-Bit-Prozessor ausführen oder laufen. Das kann möglicherweise genützt werden, um Rückwärtskompatibilität zu liefern, indem es alten 32-Bit-Anwendungen erlaubt, auf dem neueren 64-Bit-Prozessor zu laufen. In manchen Ausführungsformen können sowohl 32-Bit- als auch 64-Bit-Code innerhalb des gleichen Threads laufen. In manchen Ausführungsformen kann der 64-Bit-Prozessor einen optionalen 32-Bit- oder 64-Bit-Code-Ausführungsmodus 106, um anzuzeigen, ob derzeit 64-Bit-Code oder 32-Bit-Code (oder in manchen Ausführungsformen 32-Bit-Code und auch 64-Bit-Code) vom Prozessor ausgeführt wird. Beispielsweise kann in einer Ausführungsform der Modus 106 einen ersten 64-Bit-Modus darstellen, der das Ausführen von 64-Bit-Code, aber nicht von 32-Bit-Code, auf dem 64-Bit-Prozessor erlaubt, und einen zweiten 32-Bit-Modus, der das Ausführen von 32-Bit-Code auf dem 64-Bit-Prozessor erlaubt. In einem Aspekt kann der 32-Bit-Modus auch das Ausführen von 64-Bit-Code auf dem 64-Bit-Prozessor erlauben. In einem anderen Aspekt kann der 32-Bit-Modus das Ausführen von 64-Bit-Code auf dem 64-Bit-Prozessor nicht erlauben. Der 64-Bit-Prozessor kann optional standardmäßig im 64-Bit-Modus betrieben werden, bis eine Änderung des Modus zum 32-Bit-Modus gemacht wird, wenngleich das nicht nötig ist. Andere Prozessoren brauchen nicht notwendigerweise unterschiedliche Modi, um unterschiedliche Codearten auszuführen (z. B. können einen gemischten 32-Bit-/64-Bit-Modus haben).
  • Wie oben erläutert bietet das iPhone 5S auch Rückwärtskompatibilität, indem es die Ausführung von 32-Bit-Code auf einer 64-Bit-Architektur zulässt. Das wird gemacht, indem sowohl 32-Bit- als auch 64-Bit-Versionen der Bibliotheken vorhanden sind. Eine erste Gruppe an 32-Bit-Bibliotheken ist für 32-Bit-Code enthalten, damit verbunden und wird davon verwendet (z. B. alte 32-Bit-Mobilanwendungen). Eine zweite Gruppe von 64-Bit-Bibliotheken ist für 64-Bit-Code enthalten, damit verbunden und wird davon verwendet. Der 32-Bit-Code kann nur die 32-Bit-Bibliotheksmodule nützen. Ein potenzieller Nachteil dieses Ansatzes ist jedoch die Notwendigkeit, weiterhin 32-Bit-Bibliotheken für die Nutzung des 32-Bit-Codes bereitzustellen. Zum einen wird zusätzlicher Speicherplatz benötigt, um die 32-Bit-Bibliotheken zu speichern. Besonders bei Smartphones, Tablet-Computern und anderen kleinen elektronischen Vorrichtungen ist die Menge an Speicherplatz allgemein tendenziell beschränkt. Der zusätzliche Speicherplatz, der zum Unterbringen der 32-Bit-Bibliotheken nötig ist, tendiert auch dazu, die Gesamtherstellungskosten der Vorrichtung zu erhöhen.
  • Ein anderer potenzieller Nachteil dieses Ansatzes ist, dass der 32-Bit-Code nur die 32-Bit-Bibliotheken, nicht aber die 64-Bit-Bibliotheken nützen kann. Das schränkt tendenziell die Leistungsfähigkeit ein, da die 32-Bit-Bibliotheken allgemein nicht dazu entworfen sind, die 64-Bit-Architekturressourcen 104 verwenden zu können (z. B. fortgeschrittene Architekturressourcen und/oder leistungssteigernde Ressourcen). Diese Ressourcen sind allgemein nicht für den entsprechenden (z. B. vorhergehenden) 32-Bit-Architekturprozessor verfügbar, auf dem die Ausführung der 32-Bit-Bibliotheken bestimmt war. Die 32-Bit-Bibliotheken wurden nicht dafür entwickelt, alle diese 64-Bit-Architekturressourcen zu nützen, und sie können sie auch nicht benützen. Folglich sind die 32-Bit-Bibliotheken allgemein nicht in der Lage, die Leistungssteigerung aufgrund der 64-Bit-Architekturressourcen zu realisieren, die von den 64-Bit-Bibliotheken realisiert werden kann.
  • Sich wieder auf 1 beziehend umfasst das Computersystem eine Ausführungsform eines 32-Bit- bis und/oder von 64-Bit-(32-Bit/64-Bit)-Kompatibilitätsmoduls 122. Das 32-Bit/64-Bit-Kompatibilitätsmodul ist ein Beispiel eines architekturübergreifenden Kompatibilitätsmoduls für 32-Bit- und 64-Bit-Architekturen, wenngleich in anderen Ausführungsformen stattdessen andere Architekturen verwendet werden können. In einigen Ausführungsformen kann das 32-Bit/64-Bit-Kompatibilitätsmodul konfiguriert oder betriebsfähig sein, um einem oder mehreren 32-Bit-Modulen 116 zu erlauben, sich mit den 64-Bit-Bibliotheksmodulen 118 zu verbinden und sie zu nützen (z. B. C-Standard-Bibliothek, Mathematikbibliothek, Glibc, Systembibliotheken, etc.). in einigen Ausführungsformen kann das Kompatibilitätsmodul dem 32-Bit-Code erlauben, jedes beliebige 64-Bit-Bibliotheksmodul in seinem Adressbereich zu verwenden (z. B. im Gegensatz zu nur einer beschränkten Gruppe von Spezialmodulen wie WoW64.dll, WoW64Win.dll, Wowo4Cpu.dll oder Ntdll.dll). Das 32-Bit/64-Bit-Kompatibilitätsmodul kann konfiguriert oder betriebsfähig sein, um verschiedene Kompatibilitätsveränderungen zu machen, die dazu geeignet sind, einem oder mehreren 32-Bit-Codemodulen die Nutzung der 64-Bit-Bibliotheksmodule zu erlauben. Diese Änderungen können beispielsweise Änderungen umfassen, die Unterschiede zwischen den ABIs eines oder mehrerer 32-Bit-Codemodule und den 64-Bit-Bibliotheksmodulen ergeben. In manchen Ausführungsformen kann das 32-Bit/64-Bit-Kompatibilitätsmodul konfiguriert oder betriebsfähig sein, um Codeart-Änderungen des Ausführungsmodus zu machen (z. B. zum Wechseln zwischen 32-Bit- und 64-Bit-Code-Ausführungsmodi). In verschiedenen Ausführungsformen kann das 32-Bit/64-Bit-Kompatibilitätsmodul in Hardware (z. B. integrierte Schaltung, Transistoren oder andere Schaltelemente, etc.), Firmware (z. B. ROM, EPROM, Flash-Speicher oder andere persistente und nichtflüchtige Speicher und Mikrocode, Mikrobefehle und andere nachrangige Befehle, da darin gespeichert sind), Software (z. B. übergeordnete Befehle, die im Speicher sind), oder eine Kombination davon implementiert werden.
  • Vorteilhafterweise kann das Kompatibilitätsmodul helfen, Rückwärtskompatibilität zu bieten und dem einen oder den mehreren 32-Bit-Codemodulen erlauben, auf dem 64-Bit-Prozessor im System, das das 64-Bit-Betriebssystemmodul hat, ausgeführt zu werden oder zu laufen. Da das eine oder die mehreren 32-Bit-Codemodule in der Lage sind, die 64-Bit-Bibliotheksmodule zu nützen und nicht die 32-Bit-Bibliotheksmodule nützen müssen, können die 32-Bit-Bibliotheksmodule optional in manchen Ausführungsformen weggelassen werden. In manchen Ausführungsformen haben der Speicher und/oder das Computersystem möglicherweise keine 32-Bit-Bibliotheksmodule. Vorteilhafterweise kann das Weglassen der 32-Bit-Bibliotheksmodule helfen, Speicherplatz frei zu machen, der ansonsten dazu nötig wäre, sie zu speichern und/oder helfen, die Herstellungskosten des Systems zu reduzieren, indem eine geringere Gesamtmenge an Speicherplatz zur Verfügung gestellt werden muss. Besonders für Smartphones, Tabletcomputer und andere relativ kleine elektronische Vorrichtungen kann es ein Vorteil sein, wenn vermieden werden kann, die 32-Bit-Bibliotheksmodule speichern zu müssen. Alternativ können in anderen Ausführungsformen die 32-Bit-Bibliotheksmodule umfasst sein, wenn das gewünscht ist. In manchen Ausführungsformen kann zumindest ein 32-Bit-Codemodul in der Lage sein, zumindest ein 64-Bit-Bibliotheksmodul mit der Verwendung des Kompatibilitätsmoduls zu nützen, sogar wenn andere 32-Bit-Codemodule 32-Bit-Bibliotheksmodule nützen.
  • Vorteilhafterweise kann es auch helfen, die Leistung zu steigern, wenn 32-Bit-Codemodulen erlaubt wird, die 64-Bit-Bibliotheksmodule zu nützen. Beispielsweise können die 64-Bit-Bibliotheksmodule im Vergleich zu den 32-Bit-Bibliotheksmodulen besser in der Lage sein, die 64-Bit-Architekturressourcen 104 des 64-Bit-Prozessors zu verwenden (z. B. fortgeschrittene Architekturressourcen und/oder leistungssteigernde Ressourcen). Beispielsweise können die 64-Bit-Bibliotheksmodule in der Lage sein, mehr Register zu nützen, als für die 32-Bit-Bibliotheksmodule verfügbar sind, die 64-Bit-Bibliotheksmodule können in der Lage sein, Parameter über die Register zu übergeben, anstatt über den Stapel, wie das bei den 32-Bit-Bibliotheksmodulen der Fall ist, etc. Wenn das eine oder die mehreren 32-Bit-Bibliotheksmodule in der Lage sind, die 64-Bit-Bibliotheksmodule die gewisse benötigte Verarbeitung anstelle der 32-Bit-Bibliotheksmodule durchzuführen zu lassen, können die 64-Bit-Bibliotheksmodule in der Lage sein, die Verarbeitung schneller durchzuführen und/oder die benötigten Ergebnisse früher zu liefern. Das kann dabei helfen, die Leistung im Vergleich dazu, was erreicht worden wäre, wenn 32-Bit-Bibliotheksmodule stattdessen für die Durchführung dieser Verarbeitung verwendet worden wären, zu verbessern.
  • 1 zeigt einen 64-Bit-Prozessor, ein 64-Bit-Betriebssystem und 64-Bit- und 32-Bit-Code und -Bibliotheksmodule. Der Schutzbereich der Erfindung ist jedoch nicht so eingeschränkt. In anderen Ausführungsformen können optional andere Architekturen verwendet werden. Beispielsweise kann in manchen Ausführungsformen ein X-Bit-Architektur-Codemodul ein Y-Bit-Architektur-Bibliotheksmodul verwenden und auf einem Y-Bit-Architektur-Prozessor laufen, der ein Y-Bit-Architektur-Betriebssystem verwendet, worin X und Y unterschiedlich sind.
  • Zur weiteren Verdeutlichung zeigen 2–4 mehrere andere Ausführungsformen von Computersystemen, in welchen Ausführungsformen der Erfindung umgesetzt werden können. Die Computersysteme der 2–4 und ihre Bestandteile haben gewissen Ähnlichkeiten zum Computersystem von 1. Um eine Verzerrung der Beschreibung zu vermeiden werden die unterschiedlichen und/oder zusätzlichen Merkmale dieser Computersysteme und ihrer Bestandteile hauptsächlich beschrieben, ohne alle ähnlichen Merkmale zu wiederholen. Es muss jedoch erkennbar sein, dass diese Computersysteme und Bestandteile die gleichen, ähnlichen oder entsprechenden Merkmale der entsprechenden Bestandteile von 1 haben.
  • 2 ist ein Blockdiagramm einer zweiten Ausführungsform eines Computersystems 200, das ein 16-Bit- bis und/oder von 32-Bit-(16-Bit/32-Bit)-Kompatibilitätsmodul 222 besitzt. Das Computersystem umfasst einen 32-Bit-Prozessor 202 und einen Speicher 210. Der Speicher speichert ein 32-Bit-Betriebssystemmodul 212, eines oder mehrere 16-Bit-Codemodule 216 und 32-Bit-Bibliotheksmodule 218. Das 16-Bit/32-Bit-Kompatibilitätsmodul kann dem einen oder den mehreren 16-Bit-Codemodulen erlauben, die 32-Bit-Bibliotheksmodule zu verwenden. Der Speicher kann optional auch eines oder mehrere 32-Bit-Codemodule (nicht gezeigt) speichern, die optional auch die 32-Bit-Bibliotheksmodule verwenden können. In einigen Ausführungsformen können der Speicher und/oder das Computersystem auch 16-Bit-Bibliotheksmodule besitzen. Alternativ können die 16-Bit-Bibliotheksmodule optional weggelassen werden.
  • 3 ist ein Blockdiagramm einer dritten Ausführungsform eines Computersystems 300, das ein 64-Bit- bis und/oder von 128-Bit-(64-Bit/128-Bit)-Kompatibilitätsmodul 322 besitzt. Das Computersystem umfasst auch einen 128-Bit-Prozessor 302 und einen Speicher 310. Der Speicher speichert ein 128-Bit-Betriebssystemmodul 312, eines oder mehrere 64-Bit-Codemodule 316 und 128-Bit-Bibliotheksmodule 318. Das 64-Bit/128-Bit-Kompatibilitätsmodul kann dem einen oder den mehreren 64-Bit-Codemodulen erlauben, die 128-Bit-Bibliotheksmodule zu verwenden. Der Speicher kann optional auch eines oder mehrere 128-Bit-Codemodule (nicht gezeigt) speichern, die optional auch die 128-Bit-Bibliotheksmodule verwenden können. In einigen Ausführungsformen können der Speicher und/oder das Computersystem auch 64-Bit-Bibliotheksmodule besitzen. Alternativ können die 64-Bit-Bibliotheksmodule optional weggelassen werden.
  • 4 ist ein Blockdiagramm einer vierten Ausführungsform eines Computersystems 400, das ein 16-Bit- bis und/oder von 32-Bit-(16-Bit/32-Bit)-Kompatibilitätsmodul 422 besitzt. Das Computersystem umfasst auch einen 16-Bit-Prozessor 402 und einen Speicher 410. Der Speicher speichert ein 16-Bit-Betriebssystemmodul 412, eines oder mehrere 32-Bit-Codemodule 416 und 16-Bit-Bibliotheksmodule 418. Das 16-Bit/32-Bit-Kompatibilitätsmodul kann dem einen oder den mehreren 32-Bit-Codemodulen erlauben, die 16-Bit-Bibliotheksmodule zu verwenden. Der Speicher kann optional auch eines oder mehrere 16-Bit-Codemodule (nicht gezeigt) speichern, die optional auch die 16-Bit-Bibliotheksmodule verwenden können. In einigen Ausführungsformen können der Speicher und/oder das Computersystem auch 32-Bit-Bibliotheksmodule besitzen. Alternativ können die 32-Bit-Bibliotheksmodule optional weggelassen werden.
  • Das sind nur ein paar zusätzliche Beispiele. Es werden noch andere Ausführungsformen in Erwägung gezogen. Beispielsweise kann in noch einer anderen Ausführungsform ein 32-Bit- bis und/oder von 64-Bit-(32-Bit/64-Bit)-Kompatibilitätsmodul 64-Bit-Codemodulen erlauben, 32-Bit-Bibliotheksmodule zu verwenden, und kann auf einem 32-Bit-Prozessor mit einem 32-Bit-Betriebssystem laufen. Um gewisse Konzepte zu veranschaulichen, werden 32-Bit-Codemodule, 64-Bit-Prozessoren, 64-Bit-Betriebssysteme und 32-Bit/64-Bit-Kompatibilitätsmodule in den Figuren oft gezeigt und beschrieben werden. Es muss jedoch erkennbar sein, dass in anderen Ausführungsformen andere Architekturvariationen, die anderswo beschrieben werden, hierin geeignet sind.
  • 5 ist ein Blockdiagramm einer Ausführungsform eines Kompatibilitätsmoduls 522 einer ersten Architektur (z. B. 32-Bit) zu und/oder von einer zweiten Architektur (z. B. 64-Bit). Das Kompatibilitätsmodul erster/zweiter Architektur ist betriebsfähig, eines oder mehrere Codemodule erster Architektur (z. B. 32-Bit) 516 mit einer Gruppe Bibliotheksmodule zweiter Architektur (z. B. 64-Bit) 518 kompatibel und verwendbar zu machen. Das Kompatibilitätsmodul erster/zweiter Architektur ist zwischen dem einen oder den mehreren Codemodulen erster Architektur und den Bibliotheksmodulen zweiter Architektur gekoppelt oder kommuniziert anderweitig zwischen ihnen. In der Zeichnung sind das eine oder die mehreren Codemodule erster Architektur und die Bibliotheksmodule zweiter Architektur in gestrichelten Linien gezeigt, um darauf hinzuweisen, dass sie nicht Teil der Erfindung sind.
  • Das Komptabilitätsmodul umfasst ein Empfangsmodul für Kontrollflusstransfer 530. Das Kontrollflusstransfer-Empfangsmodul kann konfiguriert oder betriebsfähig sein, um eine Kontrollflussoperation für Eingabekontrolle wie zum Beispiel eine Prozeduraufrufoperation von einem Codemodul erster Architektur oder eine Prozedurrückgabeoperation? vom Bibliotheksmodul zweiter Architektur abzufangen oder anderweitig zu empfangen. Das Kontrollflusstransferempfangsmodul kann auch konfiguriert oder betriebsfähig sein, um eines oder mehrere Eingabeargumente oder andere Parameter entsprechend einer empfangenen Kontrollflussoperation für Eingabekontrolle zu empfangen. Beispielsweise können diese Parameter vom Stapel, von Registern, die verwendet werden, um solche Parameter zu übergeben, und anders abgerufen werden.
  • Das Kompatibilitätsmodul umfasst auch ein ABI-Änderungsmodul 532. Das ABI stellt allgemein eine Schnittstelle zwischen zwei Programmmodulen dar, von denen eines oft ein Bibliotheksmodul oder Betriebssystemmodul auf Ebene des Maschinencodes ist. Ein ABI umfasst häufig Details wie die Größen, Layouts und Datenabgleich, wie Funktionen genannt werden, die Details von Aufrufkonventionen und wie Information zwischen den Programmmodulen übergeben werden soll (z. B. wie Argumente übergeben und Rückgabewerte abgerufen werden) und dergleichen. Beispielsweise kann das ABI spezifizieren, ob Parameter zwischen den Modulen über den Stapel oder Register übergeben werden, welche speziellen Register verwendet werden, in welcher Reihenfolge die Parameter auf den Stapel gelegt werden, etc. Üblicherweise wird es zumindest einige Unterschiede zwischen der ABI des einen oder der mehreren Codemodule erster Architektur (z. B. 32-Bit) und der ABI der Bibliotheksmodule zweiter Architektur (z. B. 64-Bit) geben. Das ABI-Änderungsmodul kann konfiguriert oder betriebsfähig sein, um Änderungen zu machen, die dabei zu helfen, die Gegensätze zwischen diesen ABI-Unterschieden zu überbrücken. Das ABI-Änderungsmodul kann verschiedene Arten von ABI-Änderungen machen, abhängig von den speziellen ersten und zweiten Architekturen und den beteiligten ABIs. Beispielsweise kann das ABI-Änderungsmodul ABI-Änderungen machen, die nötig sind, um eine Kontrollflussoperation für Eingabekontrolle und seine verbundenen Parameter an eine entsprechende Kontrollflussoperation für Ausgabekontrolle und ihre verbundenen Parameter abzubilden oder zu übertragen. Als ein Beispiel kann das ABI-Änderungsmodul ABI-Änderungen machen, die nötig sind, um eine Prozeduraufrufoperation, die von dem einen oder den mehreren Codemodulen erster Architektur empfangen wurde, auf die unterschiedlichen Aufrufkonventionen einer entsprechenden Prozeduraufrufoperation abzubilden oder zu übertragen, um den Bibliotheksmodulen zweiter Architektur (z. B. möglicherweise das Zuordnen von Eingabeparametern, die über den Stapel für entsprechende Ausgabeparameter, die in Registern übergeben werden, bereitgestellt sind) ausgegeben zu werden. In manchen Ausführungsformen, abhängig von den speziellen ABIs, können auch Datengrößen oder -Formate von Eingabeparametern auf die entsprechenden Größen oder Formate der Ausgabeparameter geändert werden. Als anderes Beispiel kann das ABI-Änderungsmodul ABI-Änderungen machen, die nötig sind, um eine Prozedurrückgabeoperation, die von den Bibliotheksmodulen zweiter Architektur empfangen wurde, auf die unterschiedlichen Aufrufkonventionen einer entsprechenden Prozedurrückgabeoperation abzubilden oder zu übertragen, um für das eine oder die mehreren Codemodulen erster Architektur (z. B. möglicherweise das Zuordnen von Eingabeparametern, die in Registern an entsprechende Ausgabeparameter, die über den Stapel bereitgestellt sind, übergeben werden) bereitgestellt zu werden.
  • Sich wieder auf 5 beziehend umfasst das Kompatibilitätsmodul auch ein Prozessormodus-Änderungsmodul 534. Das Prozessormodus-Änderungsmodul kann konfiguriert oder betriebsfähig sein, um den Codeart-Ausführungsmodus des Prozessors gegebenenfalls zu ändern, um die spezielle auszuführende Codeart anzugeben (z. B. 32-Bit- oder 64-Bit-Code). Wie zuvor erwähnt können manche Prozessoren unterschiedliche Modi haben, in denen diese unterschiedlichen Codearten ausgeführt werden können, wenngleich das nicht nötig ist. Beispielsweise kann in manchen Ausführungsformen ein 64-Bit-Prozessor einen ersten 64-Bit-Modus haben, der die Ausführung von 64-Bit-Code, aber nicht von 32-Bit-Code erlaubt, und einen zweiten 32-Bit-Modus, der die Ausführung von 32-Bit-Code erlaubt. In manchen Fällen kann der zweite 32-Bit-Modus auch die Ausführung von 64-Bit-Code zulassen, aber in anderen Fällen kann der 32-Bit-Modus die Ausführung von 64-Bit-Code möglicherweise nicht zulassen. Andere Prozessoren können unterschiedliche Modi (für anderen Code als 32-Bit- und/oder 64-Bit-Code) oder zusätzliche Modi (z. B. für 16-Bit-Code zusätzlich zu 32-Bit- und 64-Bit-Code), etc. haben. Wieder andere Prozessoren brauchen nicht notwendigerweise unterschiedliche Modi für unterschiedliche Codearten. Beispielsweise kann ein Prozessor optional/potenziell einen einzigen Mischmodus (z. B. einen 32-Bit/64-Bit-Mischmodus) haben, womit unterschiedliche Codearten ausgeführt werden können. In solchen Fällen kann das Prozessormodus-Änderungsmodul optional weggelassen werden.
  • Unterschiedliche Prozessorarten können unterschiedliche Ausführungsmodi für Codearten auf unterschiedliche Weise implementieren. Als ein illustratives Beispiel geben gewisse 64-Bit-Prozessoren, die von Intel Corporation aus Santa Clara, Kalifornien, verfügbar sind, 64-Bit- und 32-Bit/64-Bit-Mischkompatibilitätsmodus über einen Codesegment-Deskriptor an. Der Codesegment-Deskriptor wird bei Speichersegmentierung verwendet. Speichersegmentierung bezieht sich allgemein auf das Aufteilen eines Speichers in Segmente oder Sektionen. Eine Referenz zu einem Speicherplatz oder einer Speicheradresse umfasst im Allgemeinen einen Segmentbezeichner und einen Offset innerhalb des bezeichneten Segments. Im Speziellen hat in diesen 64-Bit-Prozessoren der Codesegment-Bezeichner ein besonderes Bit, das als ein L-Bit bekannt ist, um den Codeart-Ausführungsmodus anzugeben. Gemäß der angenommenen Konvention wird das L-Bit zu einer binären Null (d. h. 0) gelöscht, um einen 64-Bit-Modus anzuzeigen, in dem die Ausführung von 64-Bit-Code, aber nicht von 32-Bit-Code zugelassen ist. Umgekehrt wird das L-Bit auf eine binäre Eins (d. h. 1) eingestellt, um einen 32-Bit/64-Bit-Mischkompatibilitätsmodus anzugeben, in dem sowohl 32-Bit-Code als auch 64-Bit-Code ausgeführt werden kann.
  • In solchen Ausführungsformen, bei denen der Ausführungsmodus der Codeart über den Codesegment-Deskriptor angegeben wird, kann das Prozessormodus-Änderungsmodul konfiguriert oder betriebsfähig sein, um Modusänderungsbestimmungen basierend auf dem L-Bit, dem Codesegment-Deskriptor, basierend darauf, in welchem Segment der auszuführende Code ist, etc. zu machen. Beispielsweise können in manchen Ausführungsformen unterschiedliche Codearten in unterschiedlichen Segmenten sein, wenngleich das in anderen Ausführungsformen nicht erforderlich ist. Beispielsweise kann es eines oder mehrere 32-Bit-Code-Segmente geben, die 32-Bit-Code, aber nicht 64-Bit-Code enthalten, und eines oder mehrere 64-Bit-Code-Segmente, die 64-Bit-Code, nicht aber 32-Bit-Code enthalten. In einem Beispiel gibt es ein einzelnes 32-Bit-Code-Segment, ein 64-Bit-Code-Segment für 64-Bit-Betriebssystemcode und ein 64-Bit-Code-Segment für 64-Bit-Benutzer-Level-Code und 64-Bit-Bibliotheken, wenngleich der Schutzbereich der Erfindung nicht so eingeschränkt ist. Diese 32-Bit- und 64-Bit-Code-Segmente können im Local Descriptor Table (LDT) vertreten sein. In solchen Ausführungsformen können alle Kontrollflussoperationen zwischen einem oder mehreren 32-Bit-Code-Segmenten und einem oder mehreren 64-Bit-Code-Segmenten intersegmentären oder sogenannten „weiten” Kontrollflusstransfer verwenden. In anderen Worten: Ein Übergang von der Ausführung von 64-Bit-Code zur Ausführung von 32-Bit-Code, oder von der Ausführung von 32-Bit-Code zur Ausführung von 64-Bit-Code, kann nur nach eines weiten oder intersegmentären Kontrollflusstransfers von einem anderen Segment geschehen. In solchen Ausführungsformen können solche weiten oder intersegmentären Operationen zum Kontrollflusstransfer geprüft werden, um zu wissen, wann der Transfer zwischen den Segmenten für unterschiedliche Codearten stattfindet. In einem solchen Fall kann das genützt werden, um eine Änderungsbestimmung für den Prozessorcodeart-Ausführungsmodus zu machen. Andere Prozessoren können solche Codeart-Ausführungsmodi unterschiedlich angeben und/oder Modusänderungsbestimmungen unterschiedlich machen.
  • Wie oben erwähnt kann es in manchen Ausführungsformen eines oder mehrere 32-Bit-Code-Segmente geben. In manchen Ausführungsformen können 32-Bit-Codemodule (z. B. wenn es einen alten Code gibt) basierend auf flacher Adressierung kompiliert worden sein. Bei flacher Adressierung können die Basisadresse von Code und Datensegmenten auf null eingestellt worden sein. Sowohl die Code- als auch die Datensegmente können auch auf ein Limit oder Maximum von vier Gigabyte eingestellt worden sein. In manchen Ausführungsformen können eines oder mehrere erstellte 32-Bit-Code-Segmente, die diese 32-Bit-Module haben, auch konfiguriert werden, um solch einen Ansatz der flachen Adressierung zu verwenden. Das kann dabei helfen, die Zerschlagung der Annahmen, die bei der anfänglichen Kompilierung der 32-Bit-Codemodule getroffen wurden, und/oder die Notwendigkeit, die 32-Bit-Codemodule neu zu kompilieren, zu vermeiden.
  • Sich wieder auf 5 beziehend umfasst das Kompatibilitätsmodul auch ein Ausgabemodul für den Kontrollflusstransfer 536. Das Kontrollflusstransferausgabemodul kann konfiguriert oder betriebsfähig sein, um eine Kontrollflussoperation zur Ausgabekontrolle auszugeben oder bereitzustellen, die einer Kontrollflussoperation zur Eingabekontrolle entspricht, die zuvor vom Kontrollflusstransferempfangsmodul empfangen wurde. Das Kontrollflusstransferausgabemodul kann auch konfiguriert oder betriebsfähig sein, um eine Kontrollflussoperation zur Ausgabekontrolle unter Verwendung der Richtlinien der Aufrufkonvention, die für das Zielmodul geeignet sind und gemäß der ABI-Veränderungen, die durch das ABI-Änderungsmodul gemacht wurden, durchzuführen. Beispielhalber kann das Kontrollflusstransferausgabemodul eine Prozeduraufrufoperation an die Bibliotheksmodule zweiter Architektur ausgeben, die einer anfänglichen Prozeduraufrufoperation entspricht, die von dem einen oder den mehreren Codemodulen erster Architektur durch das Kontrollflusstransfer-Empfangsmodul empfangen wurde und die Änderungen wiedergibt, welche durch das ABI-Änderungsmodul gemacht wurden.
  • 6 ist ein Blockdiagramm einer Ausführungsform eines 32-Bit/64-Bit-Kompatibilitätsmoduls 622, das eine Wrapper-Bibliothek 640 hat. In manchen Ausführungsformen kann die Wrapper-Bibliothek einer oder mehreren entsprechenden wirklichen Bibliotheken 620 einer bestimmten Architektur entsprechen oder sie widerspiegeln, welche in der Zeichnung eine 32-Bit-Bibliothek 620 ist. In manchen Ausführungsformen kann die Wrapper-Bibliothek ein Wrapper-Modul für jedes entsprechende Funktionsmodul in der wirklichen Bibliothek oder den wirklichen Bibliotheken (z. B. 32-Bit-Bibliothek) haben. In der veranschaulichten Ausführungsform umfasst die 32-Bit-Bibliothek ein erstes 32-Bit-Funktionsmodul 644-1 (z. B. hat es einen Namen „Cosine”) durch ein N-tes 32-Bit-Funktionsmodul 644-N, worin N jede für die bestimmte Implementierung geeignete Zahl sein kann. Gleichermaßen umfasst die Wrapperbibliothek ein erstes Wrapper-Modul 642-1 (z. B. hat es auch einen Namen „Cosine”) durch ein N-tes Wrapper-Modul 642-N. Das erste 32-Bit-Funktionsmodul entspricht dem N-ten Wrapper-Modul. In manchen Ausführungsformen kann die Wrapper-Bibliothek ein Wrapper-Modul für jedes Funktionsmodul in einer 32-Bit-C-Standardbibliothek umfassen, ein Wrapper-Modul für jedes Funktionsmodul in einer oder einer Gruppe von Bibliotheken (z. B. eine 32-Bit-Thread-Bibliothek, eine 32-Bit-Mathematikbibliothek, eine 32-Bit-Systembibliothek, etc.), wenngleich der Schutzumfang der Erfindung nicht so eingeschränkt ist. In manchen Ausführungsformen kann einer Gruppe von 64-Bit-Bibliotheksmodulen 618 (z. B. eine 64-Bit-Bibliothek) ein 64-Bit-Bibliotheksmodul für jedes entsprechende Funktionsmodul in der 32-Bit-Bibliothek 620 und/oder für jedes Wrapper-Modul in der Wrapper-Bibliothek 640 haben, wenngleich das nicht erforderlich ist.
  • In manchen Ausführungsformen kann die Wrapper-Bibliothek Kontrollflusstransferoperationen vom 32-Bit-Codemodul abfangen oder anderweitig empfangen, die für eine 32-Bit-Bibliothek bestimmt sind. Beispielweise kann das 32-Bit-Codemodul eine Kontrollflusstransferoperationen (z. B. eine Prozeduraufrufoperation) an das erste 32-Bit-Funktionsmodul (z. B. hat es einen Namen „Cosine”) erteilen, und das entsprechende erste Wrapper-Modul (z. B. hat es auch einen Namen „Cosine”) kann diese Kontrollflusstransferoperationen abfangen. Das Wrapper-Modul kann die empfangene Kontrollflusstransferoperationen wie hierin an anderer Stelle beschrieben verarbeiten. Beispielsweise hat das veranschaulichte erste Wrapper-Modul ein Kontrollflusstransfer-Empfangsmodul 630, ein ABI-Änderungsmodul 632, ein Prozessormodus-Änderungsmodul 634 und ein Ausgabemodul für den Kontrollflusstransfer 636. Jedes davon kann ähnlich oder gleich wie jene sein, die hierin an anderer Stelle beschrieben wurden (z. B. in Verbindung mit 5).
  • Das Kontrollflusstransferempfangsmodul kann eine entsprechende oder abgeleitete Prozeduraufruffunktion für die 64-Bit-Bibliotheksmodule bereitstellen. In manchen Ausführungsformen kann die Wrapper-Bibliothek auch Kontrollflusstransferoperationen von den 64-Bit-Bibliotheksmodulen abfangen oder anderweitig empfangen. Beispielsweise können das eine oder die mehreren 64-Bit-Bibliotheksmodule eine reagierende Prozedurrückgabeoperation erteilen, und das entsprechende erste Wrapper-Modul kann diese Kontrollflusstransferoperationen abfangen. Das erste Wrapper-Modul kann die empfangene Prozedurrückgabeoperation wie vorher beschrieben verarbeiten (z. B. ABI-Änderungen machen, etc.) und eine entsprechende oder abgeleitete Prozedurrückgabeoperation für die 32-Bit-Codemodule bereitstellen. In manchen Ausführungsformen kann das Wrapper-Modul logisch in ein Trampolinmodul, um Kontrolle (z. B. eines Aufrufs) von einem aufrufenden 32-Bit-Codemodul auf ein 64-Bit-Bibliotheksmodul zu übertragen, und ein umgekehrtes Trampolin- oder Return-Stub, um Kontrolle (z. B. eines Rücksprungs) von dem 64-Bit-Bibliotheksmodul auf das 32-Bit-Codemodule zu transferieren, partitioniert werden.
  • Die oben beschriebene Ausführungsform bezieht sich auf ein 32-Bit-Codemodul, eine 32-Bit-Bibliothek, eine 64-Bit-Bibliothek und ein 32-Bit/64-Bit-Kompatibilitätsmodul, wenngleich der Schutzumfang der Erfindung nicht so eingeschränkt ist. In anderen Ausführungsformen können diese Referenzen auf das 32-Bit-Codemodul, die 32-Bit-Bibliothek, die 64-Bit-Bibliothek und das 32-Bit/64-Bit-Kompatibilitätsmodul durch andere Architekturvarianten ersetzt werden, die an anderer Stelle beschrieben werden (z. B. jene, die für die 2–4 gezeigt und beschrieben sind).
  • 7 ist ein Blockdiagramm einer Ausführungsform eine Verfahrens 750 zum Abfangen von Kontrollflusstransfers mit einer Wrapper-Bibliothek eines architekturübergreifenden Kompatibilitätsmoduls durch die Verwendung von Funktionszwischenschaltung. In manchen Ausführungsformen kann das Verfahren mit der Wrapper-Bibliothek 640 aus 6 durchgeführt werden. Alternativ können optional ähnliche oder unterschiedliche Wrapper-Bibliotheken verwendet werden.
  • Das Verfahren umfasst die Konfiguration der Wrapper-Bibliothek, nach Funktionsmodulen durchsucht zu werden, bevor eine oder mehrere andere Bibliotheken durchsucht werden, im Block 751. Beispielsweise kann das die Konfiguration der Wrapper-Bibliothek umfassen, nach Funktionsmodulen durchsucht zu werden, bevor eine 64-Bit-Bibliothek nach dem Funktionsmodul durchsucht wird und/oder bevor eine optionale 32-Bit-Bibliothek (wenn eine vorhanden ist) nach dem Funktionsmodul durchsucht wird. Optional kann die Wrapper-Bibliothek konfiguriert werden, dass sie durchsucht wird, bevor irgendeine andere Bibliothek durchsucht wird. In manchen Ausführungsformen kann die Konfiguration der Wrapper-Bibliothek, vor der einen oder den mehreren anderen Bibliotheken durchsucht zu werden, durchgeführt werden, indem die Reihenfolge genutzt wird, in der ein dynamisches Linker-Modul nach Funktionen sucht. Üblicherweise kann das dynamische Linker-Modul in der Laufzeit in der Reihenfolge suchen, in der die Bibliotheken geladen wurden. Wenn eine erste Bibliothek vor einer zweiten Bibliothek geladen wird, dann kann das dynamische Linker-Modul in der ersten Bibliothek nach der gewünschten Funktion suchen, bevor es in der zweiten Bibliothek nach der gewünschten Funktion sucht. Dementsprechend kann die Wrapper-Bibliothek vor irgendwelchen anderen Bibliotheken geladen werden, vor denen die Durchsuchung der Wrapper-Bibliothek beabsichtigt oder erwünscht ist. In manchen Ausführungsformen kann das gemacht werden, indem die Wrapper-Bibliothek vorher geladen wird, wie beispielsweise durch die Verwendung des Befehls LD_PRELOAD. Alternativ können andere Möglichkeiten eingesetzt werden, um die Wrapper-Bibliothek zu laden. In einem Aspekt kann die Wrapper-Bibliothek vorher geladen werden oder vor der ersten Kontrollflusstransferoperation von einem Codemodul geladen werden, welches ein Bibliotheksmodul beinhaltet, das durch ein Wrapper-Modul abgefangen werden soll.
  • Das Verfahren umfasst den Empfang eines Kontrollflusstransferversuchs von dem 32-Bit-Codemodul, der für ein 32-Bit-Funktionsmodul einer Gruppe von 32-Bit-Bibliotheksmodulen im Block 752 bestimmt ist. Beispielsweise kann das den Empfang einer Prozeduraufrufoperation umfassen, die auf ein spezielles 32-Bit-Bibliotheksfunktionsmodul (z. B. hat es einen speziellen Funktionsnamen) hindeutet.
  • Das Verfahren umfasst das Durchsuchen der Wrapper-Bibliothek (z. B. vor dem Durchsuchen der 32-Bit-Bibliotheksmodule, wenn sie existieren, und/oder vor dem Durchsuchen der 64-Bit-Bibliotheksmodule) und die Identifizierung eines Wrapper-Moduls, das dem 32-Bit-Funktionsmodul entspricht, im Block 753. In manchen Ausführungsformen kann das identifizierte Wrapper-Modul einen gleichen Funktionsnamen wie das gewünschte tatsächliche Bibliotheksmodul (z. B. ein 32-Bit-Bibliotheksmodul) haben. Beispielsweise kann die Wrapper-Bibliothek nach dem 32-Bit-Funktionsmodul mit dem Namen „Cosine” durchsucht werden und ein Wrapper-Module mit ebenfalls dem Namen „Cosine” kann identifiziert werden. Alternativ kann optional eine Mapping-Tabelle oder eine andere Möglichkeit, eine Korrespondenz zwischen Wrapper-Modulen und 32-Bit-Bibliotheksfunktionsmodulen außer basierend auf ihren Namen bereitzustellen, verwendet werden.
  • Das Verfahren umfasst den Transfer von Kontrollfluss zu den identifizierten Wrapper-Modulen im Block 754. Da die Wrapper-Bibliothek konfiguriert wurde, vor der einen oder den mehreren anderen Bibliotheken durchsucht zu werden, gelangte der Kontrollflusstransfer vorteilhafterweise zu dem identifizierten Wrapper-Modul statt zu dem tatsächlichen Bibliotheksmodul. Das Wrapper-Modul war im Wesentlichen logisch zwischen dem 32-Bit-Codemodul und den tatsächlichen Bibliotheksmodulen angeordnet oder zwischengeschaltet.
  • Das Wrapper-Modul macht den versuchten Kontrollflusstransfer zu dem 32-Bit-Funktionsmodul kompatibel mit dem Kontrollflusstransfer zu einem oder mehreren 64-Bit-Funktionsmodulen im Block 755. Das kann wie hierin an anderer Stelle beschrieben gemacht werden. Beispielsweise können Eingabeparameter zu Ausgabeparametern zugeordnet werden, es können andere ABI-Änderungen gemacht werden, Ausgabeaufrufkonventionen angepasst werden, etc.
  • Das Wrapper-Modul löst den Kontrollflusstransfer von dem einen oder den mehreren 64-Bit-Funktionsmodulen im Block 756 aus. Beispielsweise kann das Wrapper-Modul eine Kontrollflusstransferoperation bereitstellen, die dem im Block 752 empfangenen Kontrollflusstransferversuch entspricht und ihn allgemein widerspiegelt.
  • Das oben beschriebene Verfahren bezieht sich auf ein 32-Bit-Codemodul, ein 32-Bit-Bibliotheksfunktionsmodul und ein 64-Bit-Bibliotheksfunktionsmodul, wenngleich der Schutzbereich der Erfindung nicht so eingeschränkt ist. In anderen Ausführungsformen können diese Referenzen zu dem 32-Bit-Codemodul, dem 32-Bit-Bibliotheksfunktionsmodul und dem 64-Bit-Bibliotheksfunktionsmodul durch andere Architekturvarianten, die hierin an anderer Stelle beschrieben werden, ersetzt werden (z. B. jene, die für die 2–4 gezeigt und beschrieben sind).
  • 8 ist ein Blockdiagramm eines Computersystems 800, das ein architekturübergreifenden Kompatibilitätsmodul 822 besitzt, das konfiguriert oder betriebsfähig ist, um Transfers zwischen unterschiedlichen Codearten 816, 818 zu ermitteln, indem es auf eine Laufzeitstruktur 868 zugreift. Das Computersystem hat einen Adressbereich 860. Der Adressbereich umfasst unterschiedliche Codearten 816, 818. In der illustrierten Beispielausführungsform umfassen diese unterschiedlichen Codearten ein 32-Bit-Codemodul 816 und ein 64-Bit-Codemodul 818, wenngleich der Schutzbereich der Erfindung nicht so eingeschränkt ist. Dementsprechend können in manchen Ausführungsformen zwei oder mehrere unterschiedliche Codearten (z. B. 32-Bit- und 64-Bit-Code) im gleichen Adressbereich enthalten oder vermischt sein. Herkömmlicherweise werden solche unterschiedlichen Arten von Codemodulen im gleichen Adressbereich allgemein nicht umfasst. Das 32-Bit-Codemodul hat einen Kopf 862, der bezeichnend für die 32-Bit-Codeart ist. Ebenso hat das 64-Bit-Codemodul einen Kopf 864, der bezeichnend für die unterschiedliche 64-Bit-Codeart ist. Ein mögliches Beispiel für eine geeignete Art von Kopf ist ein Executable-and-Linkable-Format-(ELF-)Kopf.
  • Das Computersystem beinhaltet auch ein Laufzeitlade- oder dynamisches Lademodul 866. Das dynamische Lademodul kann eine Laufzeitladefunktion einer binären ausführbaren Datei haben. Das Laufzeitlademodul erlaubt den zwei oder mehreren unterschiedlichen Codearten (z. B. 32-Bit-Code und 64-Bit-Code), im gleichen Adressbereich enthalten oder vermischt zu sein. Konventionslaufzeitbibliotheken wie Laufzeitladebibliotheken erlauben allgemein nicht, dass solche unterschiedlichen Codearten im gleichen Adressbereich enthalten oder vermischt sind. Das Laufzeitlademodul hat eine Laufzeitstruktur 868 (z. B. eine Datenstruktur). Das Laufzeitlademodul kann konfiguriert oder betriebsfähig sein, um die Art des Codes oder Bibliotheksmoduls (z. B. ob es 32-Bit oder 64-Bit ist) zur Zeit des Ladens dieses Codes oder Bibliotheksmoduls in den Adressbereich nachzuverfolgen. Beispielsweise kann das Laufzeitlademodul auf die Köpfe 862, 864 der 32-Bit- und 64-Bit-Codemodule zugreifen und die angezeigten Codearten ermitteln. Das Laufzeitlademodul kann die Codearten 869 in der Laufzeitstruktur speichern. Das Laufzeitlademodul kann optional auch die Codeadressen 870 (z. B. eine Basislaufzeitadresse des Codeabschnitts) und/oder die Codegrößen 871 in der Laufzeitstruktur speichern, auch wenn das nicht erforderlich ist. In manchen Ausführungsformen können andere Binärsystemmodule, die das Laufzeitlademodul 866 ausmachen, und/oder die helfen, die Aspekte des dynamischen Ladens umzusetzen, geändert werden. Beispielsweise können Linker, Loader und Glibc geändert werden, um unterschiedlichen Codearten zu erlauben, im gleichen Adressbereich enthalten oder vermischt zu sein. Beispielhalber können solche Module angepasst werden, um sich mit der Laufzeitstruktur 868 und den Codearten 869 zu verbinden und sie zu verwenden.
  • Sich wieder auf 8 beziehend umfasst das Computersystem auch das architekturübergreifende Kompatibilitätsmodul 822. In dem veranschaulichten Beispiel ist das Kompatibilitätsmodul ein 32-Bit-/64-Bit-Kompatibilitätsmodul, wenngleich der Schutzrahmen der Erfindung nicht so eingeschränkt ist. Das 32-Bit-/64-Bit-Kompatibilitätsmodul umfasst ein Prozessormodus-Änderungsmodul 834. Das Prozessormodus-Änderungsmodul und/oder das 32-Bit-/64-Bit-Kompatibilitätsmodul sind mit dem Laufzeitlademodul und/oder der Laufzeitstruktur gekoppelt oder kommunizieren anderweitig mit ihnen. Das Prozessormodus-Änderungsmodul und/oder das 32-Bit-/64-Bit-Kompatibilitätsmodul sind auch mit einem Codeart-Ausführungsmodus 806 eines Prozessors gekoppelt oder kommunizieren anderweitig mit ihm.
  • In manchen Ausführungsformen kann das 32-Bit-/64-Bit-Kompatibilitätsmodul konfiguriert oder betriebsfähig sein, um zu ermitteln, ob Kontrollflusstransfers zwischen unterschiedlichen Codearten, zum Beispiel zwischen 32-Bit- und 64-Bit-Code, durch Zugriff auf die Laufzeitstruktur 868 stattfinden. Beispielsweise kann das Kompatibilitätsmodul die Laufzeitstruktur nützen, um zu ermitteln, ob der Zielcode, an welchen der Kontrollflusstransfer gerichtet ist, 32-Bit- oder 64-Bit-Code ist. In manchen Ausführungsformen kann, immer wenn eine Kontrollflusstransferoperation durchgeführt wird (oder in manchen Ausführungsformen immer wenn eine weite oder intersegmentäre Kontrollflusstransferoperation durchgeführt wird), das Prozessormodus-Änderungsmodul auf die Codearten 869 in der Laufzeitstruktur zugreifen. In manchen Ausführungsformen kann das Kompatibilitätsmodul ein Signal von solchen Kontrollflusstransferoperationen 872 empfangen. Das Prozessormodus-Änderungsmodul kann betriebsfähig sein, diese Codearten zu verwenden, um zu ermitteln, ob die Codeart am Zielort gleich wie die aktuelle Codeart ist und/oder ob der aktuelle Codeartausführungsmodus 806 des Prozessors verändert werden muss.
  • Das hierin beschriebene architekturübergreifende Kompatibilitätsmodul kann auf unterschiedliche Arten in unterschiedlichen Ausführungsformen umgesetzt werden. Um gewisse Konzepte weiter zu veranschaulichen, kann es hilfreich sein, weitere Details eines möglichen Beispiels einer Art, auf die ein architekturübergreifendes Kompatibilitätsmodul in einer 64-Bit-Version in einer Android-Umgebung umgesetzt werden kann, zu betrachten. Android ist ein Betriebssystem basierend auf dem Linux-Kernel, das größtenteils für Touchscreen-Mobilgeräte wie Smartphones und Tabletcomputer verwendet wird. Die erwartete 64-Bit-Android-Umgebung kann eine mit 64-ABI kompatible Version des Android-Frameworks (Dalvik, zygote, Systembibliotheken wie glibc, etc.) und einen Linux-Kernel, der auf einem 64-Bit-Prozessor läuft, umfassen. Das mit 64-Bit-ABI kompatible Dalvik, welches die prozessbasierte virtuelle Maschine von Android ist, kann eine Fähigkeit von Dalvik umfassen, einen JNI-Aufruf an eine 64-Bit-Bibliothek zu verarbeiten und 64-Bit-JIT-(Just-in-Time)-Code zu generieren.
  • Es gibt unterschiedliche Arten von Android-Anwendungen. Eine Art sind reine Java-Anwendungen. Reine Java-Anwendungen beinhalten nur Java-Bytecode, aber keinen nativen oder architekturspezifischen Code. Android kann solchen reinen Java-Bytecode ausführen, indem es die virtuelle Maschine Dalvik aufruft. Allgemein können reine Java-Anwendungen ohne weitere Änderungen der Android-Umgebung ausgeführt werden.
  • Eine andere Art von Android-Anwendung ist eine native Anwendung. Native Anwendungen beinhalten nativen oder architekturspezifischen Code. Beispielsweise können native Anwendungen sowohl Java-Bytecode als auch nativen Code haben. Mathematikbibliotheken, Grafikbibliotheken, Systembibliotheken, C-Standardbibliotheken und dergleichen können in diese Kategorie fallen. Der native Code kann durch Verwendung von Javas JNI-Technologie (Java Native Interface) ausgeführt werden. Beispielsweise kann die native Anwendung JNI-Interface verwenden, um native Verfahren aufzurufen. Der Aufruf an das native Verfahren kann durch Verwendung von invoke_direct-Dalvik-Bytecode in Dex-Datei vertreten sein. Das invoke direct kann ein Verfahren mit Parametern aufrufen und/oder ein Verfahren zum Aufrufen angeben. In manchen Ausführungsformen kann die Art, auf die der invoke_direct-Bytecode in Dalvik implementiert wird, geändert werden, um architekturübergreifende Funktionsfähigkeit und Kompatibilität (z. B. einem 32-Bit-Codemodul erlauben, ein 64-Bit-Bibliotheksmodul und die 64-Bit-ABI zu verwenden) zuzulassen.
  • Um das weiter zu veranschaulichen, betrachtet man einen repräsentativen Aufrufstapelfluss, der verwendet wird, um invoke_direct-Bytecode in Dalvik zu implementieren. Wenn eine Anwendung ein natives Bibliotheksmodul aufruft, verwendet Dalvik einen System.loadLibrary-Aufruf, um das native Bibliotheksmodul in den Adressbereich zu laden. Dann ruft Dalviks System.loadLibrary Runtime.loadLibrary auf. Runtime.loadLibrary macht dann einen JNI-Aufruf an nativeLoad. nativeLoad ruft dann dvmLoadNativeCode auf. Dieses Modul, dvmLoadNativeCode, implementiert den Kern von loadLibrary. Beispielsweise würde dvmLoadNativeCode herkömmlicherweise ein natives 32-Bit-Bibliotheksmodul als Reaktion auf den Aufruf des nativen 32-Bit-Bibliotheksmoduls von einem 32-Bit-Codemodul laden.
  • In manchen Ausführungsformen kann invoke_direct geändert werden, um architekturübergreifende Funktionsfähigkeit und Kompatibilität wie hierin an anderer Stelle beschrieben zuzulassen. Beispielsweise kann invoke_direct geändert werden, um einem 32-Bit-Codemodul zu erlauben, ein 64-Bit-Bibliotheksmodul und die 64-Bit-ABI (z. B. einen Aufruf an ein natives 32-Bit-Bibliotheksmodul einem Aufruf an ein natives 64-Bit-Bibliotheksmodul zuordnen) zu verwenden. Beispielsweise kann invoke_direct geändert werden, um einen Aufruf von einem 32-Bit-Codemodul (z. B. einer mobilen Anwendung) abzufangen, der für ein natives 32-Bit-Bibliotheksmodul bestimmt ist, und um geeignete ABI-Änderungen zu machen, um den empfangenen Aufruf einem entsprechenden Ausgabeaufruf an das native 64-Bit-Bibliotheksmodul zuzuordnen. In manchen Ausführungsformen kann invoke_direct optional Wrapper-Module mit Eigenschaften wie hierin an anderer Stelle beschrieben umfassen, wenngleich das nicht erforderlich ist. In manchen Ausführungsformen kann die Reihenfolge, in der die nativen Bibliotheksmodule durchsucht werden, gesteuert werden, sodass ein Wrapper-Modul zuerst identifiziert wird (z. B. vor einem nativen 32-Bit-Bibliotheksmodul und/oder einem 64-Bit-Bibliotheksmodul). Beispielsweise können die Prioritäten der Pfade zu Wrapper-Modulen mehr Priorität bekommen als die Pfade zu nativen 32-Bit- und 64-Bit-Bibliotheksmodulen. Das kann eingesetzt werden, um einem Wrapper-Modul zu erlauben, einen Aufruf abzufangen (z. B. an ein 32-Bit-Bibliotheksmodul).
  • In manchen Ausführungsformen kann dvmLoadNativeCode auch verändert werden, um die Codeart (z. B. 32-Bit-Code oder 64-Bit-Code) nachzuverfolgen, die ausgeführt wird (z. B. um Prozessorcodeart-Ausführungsmodusschalter zu implementieren). Beispielsweise kann dvmLoadNativeCode verändert werden, um eine Laufzeitstruktur und/oder Codeartinformation zu umfassen und zu verwenden (z. B. ähnlich der Codeart 869 aus 8).
  • Exemplarische Kernarchitekturen, Prozessoren und Computerarchitekturen
  • Prozessorkerne können auf unterschiedliche Weise, zu unterschiedlichen Zwecken und in unterschiedlichen Prozessoren implementiert werden. Beispielsweise können Implementierungen solcher Kerne umfassen: 1) einen universellen In-Order-Kern, bestimmt für allgemeine Datenverarbeitung; 2) einen leistungsstarken universellen Out-of-Order-Kern, bestimmt für allgemeine Datenverarbeitung; 3) einen Spezialkern, hauptsächlich bestimmt für Grafikverarbeitung und/oder wissenschaftliches Rechnen (Durchsatz). Implementierungen unterschiedlicher Prozessoren können umfassen: 1) eine CPU, die einen oder mehrere universelle In-Order-Kerne umfasst, bestimmt für allgemeine Datenverarbeitung, und/oder einen oder mehrere universelle Out-of-Order-Kerne, bestimmt für allgemeine Datenverarbeitung; und 2) einen Coprozessor, der einen oder mehrere Spezialkerne umfasst, hauptsächlich bestimmt für Grafikverarbeitung und/oder wissenschaftliches Rechnen (Durchsatz). Solche unterschiedlichen Prozessoren führen zu unterschiedlichen Computersystemarchitekturen, welche umfassen können: 1) den Coprozessor auf einem vom CPU separaten Chip; 2) den Coprozessor auf einem separaten Chip im gleichen Gehäuse wie ein CPU; 3) den Coprozessor auf demselben Chip wie ein CPU (in diesem Fall wird ein solcher Coprozessor manchmal Speziallogik, wie integrierte Grafiklogik und/oder wissenschaftliche Logik (Durchsatz), oder Spezialkerne genannt; und 4) ein System auf einem Chip, das auf demselben Chip den beschriebenen CPU (manchmal als der oder die Anwendungskerne oder Anwendungsprozessoren bezeichnet), den oben beschriebenen Coprozessor und zusätzliche Funktionalitäten umfasst. Exemplarische Kernarchitekturen werden als nächstes beschrieben, gefolgt von Beschreibungen exemplarischer Prozessoren und Computerarchitekturen.
  • Exemplarische Kernarchitekturen
  • In-Order- und Out-of-Order-Kernblockdiagramm
  • 9A ist ein Blockdiagramm, das sowohl eine exemplarische In-Order-Pipeline als auch eine exemplarische Pipeline zur Registerumbenennung mit Ausgabe/Ausführung in anderer Reihenfolge (out-of-Order) gemäß den Ausführungsformen der Erfindung veranschaulicht. 9B ist ein Blockdiagramm, das sowohl eine exemplarische Ausführungsform eines In-Order-Architekturkerns als auch einen exemplarischen Architekturkern zur Registerumbenennung mit Ausgabe/Ausführung in anderer Reihenfolge (out-of-Order), der in einem Prozessor einzuschließen ist, gemäß den Ausführungsformen der Erfindung veranschaulicht. Die Kästen mit den durchgehenden Linien in 9A–B veranschaulichen die In-Order-Pipeline und den In-Order-Kern, während der optionale Zusatz der Kästen mit den gestrichelten Linien die Pipeline und den Kern zur Registerumbenennung mit Ausgabe/Ausführung in anderer Reihenfolge (out-of-Order) veranschaulicht. Angesichts dessen, dass der In-Order-Aspekt eine Untermenge des Out-Of-Order-Aspekts ist, wird der Out-Of-Order-Aspekt beschrieben.
  • In 9A umfasst eine Prozessor-Pipeline 900 eine Ladephase 902, eine Längendekodierungsphase 904, eine Dekodierungsphase 906, eine Zuteilungsphase 908, eine Umbenennungsphase 910, eine Planungsphase 912 (auch bekannt als Verteilungs- oder Ausgabephase), eine Registerlese-/Speicherlesephase 914, eine Ausführungsphase 916, eine Rückschreibe-/Speicherschreibephase 918, eine Ausnahmebehandlungsphase 922 und eine Einspeicherungsphase 924.
  • 9B zeigt Prozessorkern 990, der eine Vorverarbeitungseinheit 930 umfasst, die mit einer Ausführungsengineeinheit 950 gekoppelt ist, und beide sind mit einer Speichereinheit 970 gekoppelt. Der Kern 990 kann ein RISC-Kern (Reduced Instruction Set Computing), ein CISC-Kern (Complex Instruction Set Computing), ein VLIW-Kern (Very Long Instruction Word) oder eine hybride oder alternative Kernart sein. Als noch eine andere Möglichkeit kann der Kern 990 ein Spezialkern sein, wie beispielsweise ein Netzwerk- oder Datenübertragungskern, Komprimierungsmechanismus, Coprozessor-Kern, GPGPU-Kern (General Purpose Computation Graphics Processing Unit), Grafikkern oder dergleichen.
  • Die Vorverarbeitungseinheit 930 umfasst eine Sprungvorhersageneinheit 932, die mit einer Befehlscache-Einheit 934 gekoppelt ist, die mit einem Befehlsübersetzungspuffer (TLB) 936 gekoppelt ist, der mit einer Befehlsladeeinheit 938 gekoppelt ist, die mit einer Dekodierungseinheit 940 gekoppelt ist. Die Dekodierungseinheit 940 (oder Dekodierer) kann Befehle dekodieren und als Ausgang eine oder mehrere Mikrooperationen, Mikrocode-Einsprungstellen, Mikrobefehle, andere Befehle oder andere Steuersignale generieren, welche von den Originalbefehlen dekodiert sind, sie anderweitig widerspiegeln oder von ihnen abgeleitet sind. Die Dekodierungseinheit 940 kann durch die Verwendung unterschiedlicher Mechanismen implementiert werden. Beispiele geeigneter Mechanismen umfassen, sind aber nicht darauf beschränkt, Verweistabellen, Hardware-Implementierungen, programmierbare logische Anordnung (PLAs), Mikrocode-Festwertspeicher (ROMs), etc. In einer Ausführungsform umfasst der Kern 990 einen Mikrocode-Festwertspeicher oder anderes Medium, das Mikrocode für gewisse Makrobefehle speichert (z. B. in der Dekodierungseinheit 940 oder anderweitig innerhalb der Vorverarbeitungseinheit 930). Die Dekodierungseinheit 940 ist mit einer Umbenennungs-/Zuteilungseinheit 952 in der Ausführungsengineeinheit 950 gekoppelt.
  • Die Ausführungsengineeinheit 950 umfasst die Umbenennungs-/Zuteilungseinheit 952, die mit einer Ausscheidungseinheit 954 und einer Gruppe einer oder mehrerer Steuerprogrammeinheiten 956 gekoppelt ist. Die eine oder die mehreren Steuerprogrammeinheiten 956 stellen irgendeine Zahl unterschiedlicher Steuerprogramme dar, einschließlich Reservierungsstationen, zentrales Befehlsfenster, etc. Die eine oder die mehreren Steuerprogrammeinheiten 956 sind mit der einen oder den mehreren physischen Registerspeichereinheiten 958 gekoppelt. Jede der einen oder der mehreren physischen Registerspeichereinheiten 958 stellt eine oder mehrere physische Registerspeicher dar, wovon unterschiedliche eine oder mehrere verschiedene Datenarten speichern, wie skalare Ganzzahl, skalares Gleitkomma, gepackte Ganzzahl, gepacktes Gleitkomma, Vektorganzzahl, Vektorgleitkomma, Status (z. B. ein Befehlszeiger, der die Adresse des nächsten auszuführenden Befehls ist), etc. In einer Ausführungsform umfassen die eine oder die mehreren physischen Registerspeichereinheiten 958 eine Vektorregistereinheit, eine Schreibmaskenregistereinheit und eine Skalarregistereinheit. Diese Registereinheiten können architektonische Vektorregister, Vektormaskenregister und Universalregister bereitstellen. Die eine oder die mehreren physischen Registerspeichereinheiten 958 werden von der Ausscheidungseinheit 954 überlappt, um verschiedene Möglichkeiten zu veranschaulichen, wie Registerumbenennung und Ausführung in anderer Reihenfolge (out-of-Order) implementiert werden können (z. B. durch Verwendung von einem oder mehreren Reorder-Puffern und einem oder mehreren Ausscheidungsregisterspeichern; durch Verwendung von einem oder mehreren Zukunftsregisterspeichern, einem oder mehreren Historienpuffern und einem oder mehreren Ausscheidungsregisterspeichern; durch Verwendung von Registerkarten und einem Registerpool etc.). Ausscheidungseinheit 954 und die eine oder die mehreren physischen Registerspeichereinheiten 958 sind mit dem oder den Ausführungsclustern 960 gekoppelt. Das oder die Ausführungscluster 960 umfassen eine Gruppe von einer oder mehreren Ausführungseinheiten 962 und eine Gruppe von einer oder mehreren Speicherzugriffseinheiten 964. Die Ausführungseinheiten 962 können verschiedene Operationen (z. B. Verschiebungen, Addition, Subtraktion, Multiplikation) an verschiedenen Datenarten (z. B. skalares Gleitkomma, gepackte Ganzzahl, gepacktes Gleitkomma, Vektorganzzahl, Vektorgleitkomma) ausführen. Während einige Ausführungsformen mehrere Ausführungseinheiten umfassen können, die speziellen Funktionen oder Gruppen von Funktionen gewidmet sind, können andere Ausführungsformen nur eine Ausführungseinheit oder mehrere Ausführungseinheiten umfassen, die alle jeweils alle Funktionen ausführen. Die eine oder die mehreren Steuerprogrammeinheiten 956, die eine oder die mehreren physischen Registerspeichereinheiten 958 und das eine oder die mehreren Ausführungscluster 960 sind als möglicherweise mehrfach gezeigt, da manche Ausführungsformen separate Pipelines für gewisse Arten von Daten/Operationen schaffen (z. B. eine Skalarganzzahl-Pipeline, eine Pipeline für Gleitkomma/gepackte Ganzzahl/gepacktes Gleitkomma/Vektorganzzahl/Vektorgleitkomma und/oder eine Speicherzugriffspipeline, die alle ihre eigene Steuerprogrammeinheit, eine oder mehrere physische Registerspeichereinheiten und/oder Ausführungscluster haben – und im Fall einer separaten Speicherzugriffspipeline, werden gewissen Ausführungsformen implementiert, in denen nur das Ausführungscluster dieser Pipeline die eine oder die mehreren Speicherzugriffseinheiten 964 besitzt). Es soll auch verstanden werden, dass bei Verwendung separater Pipelines eine oder mehrere davon Pipelines zur Ausgabe/Ausführung in anderer Reihenfolge (out-of-Order) und der Rest In-Order-Pipelines sein können.
  • Die Gruppe von Speicherzugriffseinheiten 964 ist mit der Speichereinheit 970 gekoppelt, die eine Datenbefehlsübersetzungspuffereinheit 972 umfasst, die mit einer Datencache-Einheit 974 gekoppelt ist, die mit einer Level-2-(L2)-Cache-Einheit 976 gekoppelt ist. In einer exemplarischen Ausführungsform können die Speicherzugriffseinheiten 964 eine Ladeeinheit, eine Speicheradresseneinheit und eine Speicherdateneinheit umfassen, wovon jede mit der Datenbefehlsübersetzungspuffereinheit 972 in der Speichereinheit 970 gekoppelt ist. Die Befehlscache-Einheit 934 ist ferner mit einer Level-2-(L2)-Cache-Einheit 976 in der Speichereinheit 970 gekoppelt. Die Level-2-(L2)-Cache-Einheit 976 ist mit einem oder mehreren anderen Cache-Leveln und schließlich mit einem Hauptspeicher gekoppelt.
  • Beispielhalber, die exemplarische Registerumbenennung, kann die Kernarchitektur zur Ausgabe/Ausführung in anderer Reihenfolge (out-of-Order) die Pipeline 900 wie folgt implementieren: 1) der Befehlsaufruf 938 führt die Lade- und Längendekodierungsphasen 902 und 904 aus; 2) die Dekodierungseinheit 940 führt die Dekodierungsphase 906 aus; 3) die Umbenennungs-/Zuteilungseinheit 952 führt die Zuteilungsphase 908 und die Umbenennungsphase 910 aus; 4) die eine oder die mehreren Steuerprogrammeinheiten 956 führen die Planungsphase 912 aus; 5) die eine oder die mehreren physischen Registerspeichereinheiten 958 und die Speichereinheit 970 führen die Registerlese-/Speicherlesephase 914 aus; die Ausführungscluster 9601 führen die Ausführungsphase 916 aus; 6) die Speichereinheit 970 und die eine oder die mehreren physischen Registerspeichereinheiten 958 führen die Rückschreibe-/Speicherschreibephase 918 aus; 7) verschiedene Einheiten können in der Ausnahmebehandlungsphase 922 beteiligt sein; und 8) die Ausscheidungseinheit 954 und die eine oder die mehreren physischen Registerspeichereinheiten 958 führen die Einspeicherungsphase 924 aus.
  • Der Kern 990 kann einen oder mehrere Befehlssätze unterstützen (z. B. der x86-Befehlssatz (mit einigen Erweiterungen, die mit den neueren Versionen hinzugefügt wurden); der MIPS-Befehlssatz von MIPS Technologies, Sunnyvale, Kalifornien; der ARM-Befehlssatz (mit optionalen zusätzlichen Erweiterungen wie NEON) von ARM Holdings, Sunnyvale, Kalifornien), einschließlich der oder die hierin beschriebenen Befehle. In einer Ausführungsform umfasst der Kern 990 Logik zur Unterstützung einer gepackten Erweiterung von Datenbefehlssätzen, womit den Operationen, die von vielen Multimedia-Anwendungen verwendet werden, erlaubt wird, durch die Verwendung der gepackten Daten ausgeführt zu werden.
  • Es soll verstanden werden, dass der Kern Multithreading (die Ausführung von zwei oder mehreren parallelen Sätzen von Operationen oder Threads) unterstützen kann und das auf vielfältige Weise machen kann, einschließlich Zeitscheiben-Multithreading, simultanes Multithreading (bei dem ein einzelner physischer Kern einen logischen Kern für jeden dieser Threads, mit denen durch den physischen Kern simultanes Multithreading stattfindet, bereitstellt) oder eine Kombination daraus (z. B. Zeitscheibenabruf und -dekodierung und danach simultanes Multithreading wie bei der Hyperthreading-Technologie von Intel®).
  • Obwohl die Registerumbenennung im Kontext der Ausführung in anderer Reihenfolge (out-of-Order) beschrieben wird, soll klargestellt werden, dass Registerumbenennung in einer Architektur in fester Reihenfolge (in-Order) verwendet werden kann. Obwohl die veranschaulichte Ausführungsform des Prozessors auch separate Befehls- und Datencache-Einheiten 934/974 und gemeinsame L2-Cache-Einheiten 976 umfasst, können alternative Ausführungsformen einen einzelnen internen Cache für sowohl Befehle als auch Daten, wie beispielsweise ein interner Level-1-(L1)-Cache, oder mehrere Ebenen des internen Caches haben. In manchen Ausführungsformen kann das System eine Kombination eines internen Caches und eines externen Caches, der außerhalb des Kerns und/oder des Prozessors liegt, umfassen. Alternativ kann der gesamte Cache außerhalb des Kerns und/oder Prozessors liegen.
  • Spezifische exemplarische In-Order-Kernarchitektur
  • 10A–B veranschaulichen ein Blockdiagramm einer spezifischeren exemplarischen In-Order-Kernarchitektur, deren Kern einer von mehreren Logikblocks (einschließlich andere Kerne derselben Art und/oder unterschiedlicher Art) in einem Chip wäre. Die Logikblocks kommunizieren über ein Verbindungsnetzwerk großer Bandbreite (z. B. ein Ringnetzwerk) mit einiger fester Funktionslogik, Speicherein-/ausgabeschnittstellen und anderer notwendiger Eingabe-/Ausgabelogik, abhängig von der Anwendung.
  • 10A ist ein Blockdiagramm eines einzelnen Prozessorkerns, zusammen mit seiner Verbindung zu dem Ein-Chip-Verbindungsnetzwerk 1002 und mit seiner lokalen Untermenge des Level-2-(L2)-Cache 1004, gemäß der Ausführungsformen der Erfindung. In einer Ausführungsform unterstützt ein Befehlsdekodierer 1000 den x86-Befehlssatz mit einer gepackten Datenbefehlssatzerweiterung. Ein L1-Cache 1006 erlaubt Zugriffe mit geringen Latenzzeiten auf Cachespeicher in den Skalar- und Vektoreinheiten. Während in einer Ausführungsform (um den Aufbau zu vereinfachen) eine Skalareinheit 1008 und eine Vektoreinheit 1010 separate Registersätze verwenden (jeweils Skalarregister 1012 und Vektorregister 1014), und zwischen ihnen übertragene Daten in den Speicher geschrieben und dann von einem Level-1-(L1)-Cache 1006 zurückgelesen werden, können alternative Ausführungsformen der Erfindung einen unterschiedlichen Ansatz verwenden (z. B. einen einzelnen Registersatz verwenden oder einen Kommunikationspfad einschließen, der Daten erlaubt, zwischen den beiden Registerdateien übertragen zu werden, ohne geschrieben und zurückgelesen zu werden).
  • Die lokale Untermenge des L2-Cache 1004 ist Teil eines globalen L2-Cache, der in separate lokale Untermengen geteilt ist, eine pro Prozessorkern. Jeder Prozessorkern hat einen direkten Zugriffspfad zu seiner eigenen lokalen Untermenge des L2-Cache 1004. Von einem Prozessorkern gelesene Daten werden seiner Untermenge des L2-Cache 1004 gespeichert und auf sie kann schnell zugegriffen werden, parallel mit anderen Prozessorkernen, die auf ihre eigenen lokalen Untermengen des L2-Cache zugreifen. Von einem Prozessorkern geschriebene Daten werden in seiner eigenen Untermenge des L2-Cache 1004 gespeichert und wenn nötig von anderen Untermengen gelöscht. Das Ringnetzwerk stellt Kohärenz für gemeinsame Daten sicher. Das Ringnetzwerk ist bidirektional, um Agenten wie Prozessorkernen, L2-Caches und anderen Logikblocks zu erlauben, innerhalb des Chips miteinander zu kommunizieren. Jeder Ringdatenpfad ist pro Richtung 1012 Bits breit.
  • 10B ist eine erweiterte Ansicht eines Teils des Prozessorkerns in 10A gemäß den Ausführungsformen der Erfindung. 10B umfasst einen L1-Datencache 1006, einen Teil des L1-Cache 1004 sowie nähere Details hinsichtlich der Vektoreinheit 1010 und der Vektorregister 1014. Im Speziellen ist die Vektoreinheit 1010 eine 16-Bit-Vektorprozessoreinheit (VPU) (siehe die 16-Bit-ALU 1028), welche eine oder mehrere der Befehle in Ganzzahlen, Gleitkommazahlen einfacher Genauigkeit und Gleitkommazahlen doppelter Genauigkeit ausführt. Der VPU unterstützt das Swizzeln der Registereingänge mit einer Swizzle-Einheit 1020, die numerische Umwandlung mit numerischen Umwandlungseinheiten 1022A–B und Replikation mit einer Replikationseinheit 1024 auf dem Speichereingang. Schreibmaskenregister 1026 erlauben es, resultierende Vektoreinträge vorherzusagen.
  • Prozessor mit integriertem Speichercontroller und integrierter Grafik
  • 11 ist ein Blockdiagramm eines Prozessors 1100, der mehr als einen Kern haben kann, einen integrierten Speichercontroller und integrierte Grafik haben kann, gemäß den Ausführungsformen der Erfindung. Die Kästen mit der durchgehenden Linie in 11 veranschaulichen einen Prozessor 1100 mit einem einzelnen Kern 1102A, einen Systemagenten 1110, eine Gruppe einer oder mehrerer Bus-Controller-Einheiten 1116, während das optionale Hinzufügen der Kästen mit den gestrichelten Linien einen alternativen Prozessor 1100 mit mehreren Kernen 1102A–N, eine Gruppe einer oder mehrerer integrierter Speichercontroller-Einheiten 1114 in der Systemagenteneinheit 1110 und eine Speziallogik 1108 veranschaulicht.
  • Folglich können unterschiedliche Implementierungen des Prozessors 1100 umfassen: 1) einen CPU mit der Speziallogik 1108, die integrierte Grafiklogik und/oder wissenschaftliche Logik (Durchsatz) ist (welche eine oder mehrere Kerne umfassen kann), und die Kerne 1102A–N, die einer oder mehrere Universalkerne sind (z. B. universelle Kerne in fester Reihenfolge (in-order), universelle Kerne in anderer Reihenfolge (out-of-Order), eine Kombination der beiden); 2) ein Coprozessor mit den Kernen 1102A–N, die eine Vielzahl an Spezialkernen sind, hauptsächlich bestimmt für Grafik und/oder wissenschaftlichen Durchsatz; und 3) einen Coprozessor, dessen Kerne 1102A–N eine Vielzahl an universellen In-Order-Kernen sind. Folglich kann der Prozessor 1100 ein Universalprozessor, Coprozessor oder Spezialprozessor sein, wie beispielsweise ein Netzwerk- oder Kommunikationsprozessor, Komprimierungsmechanismus, Grafikprozessor, GPGPU (General Purpose Graphics Processing Unit), ein Hochdurchsatz-MIC-(Many Integrated Core)-Coprozessor (der 30 oder mehr Kerne umfasst), eingebetteter Prozessor oder dergleichen. Der Prozessor kann in einen oder mehrere Chips implementiert werden. Der Prozessor 1100 kann Teil sein von und/oder in eines oder mehrere Substrate implementiert werden, unter Verwendung einer beliebigen Anzahl an Prozesstechnologien wie beispielsweise BiCMOS, CMOS oder NMOS.
  • Die Speicherhierarchie umfasst eine oder mehrere Cache-Ebenen innerhalb der Kerne, eine Gruppe von einer oder mehreren gemeinsamen Cache-Einheiten 1106 und externen Speicher (nicht gezeigt), der mit der Gruppe von integrierten Speichercontroller-Einheiten 1114 gekoppelt ist. Die Gruppe von gemeinsamen Cache-Einheiten 1106 kann einen oder mehrere mittlere Caches, wie Level 2 (L2), Level 3 (L3), Level 4 (L4) oder andere Cache-Ebenen, einen Last-Level-Cache (LLC) und/oder eine Kombination davon umfassen. Während in einer Ausführungsform eine ringbasierte Verbindungseinheit 112 die integrierte Grafiklogik 1108, die Gruppe von gemeinsamen Cache-Einheiten 1106 und die Systemagenteneinheit 1110/die eine oder die mehreren integrierten Speichercontrollereinheiten 1114 verbindet, können alternative Ausführungsformen eine beliebige Anzahl an wohlbekannten Verfahren für die Verbindung solcher Einheiten verwenden. In einer Ausführungsform wird Kohärenz zwischen einer oder mehreren Cache-Einheiten 1106 und Kernen 1102A–N beibehalten.
  • In manchen Ausführungsformen sind einer oder mehrere der Kerne 1102A–N zu Multithreading in der Lage. Der Systemagent 1110 umfasst diese Komponenten koordinierenden und betreibenden Kerne 1102A–N. Die Systemagenteneinheit 1110 kann beispielsweise eine Leistungssteuereinheit (PCU) und eine Anzeigeeinheit umfassen. Die PCU kann Logik und Komponenten, die zur Regulierung des Leistungsstands der Kerne 1102A–N und der integrierten Grafiklogik 1108 nötig sind, sein oder umfassen. Die Anzeigeeinheit dient dem Antrieb eines oder mehrerer extern verbundener Bildschirme.
  • Die Kerne 1102A–N können homogen oder heterogen hinsichtlich des Architekturbefehlssatzes sein; das heißt, zwei oder mehr der Kerne 1102A–N können zur Ausführung desselben Befehlssatzes in der Lage sein, während andere nur zur Ausführung einer Untermenge dieses Befehlssatzes oder eines unterschiedlichen Befehlssatzes in der Lage sein können.
  • Exemplarische Computerarchitekturen
  • 12–15 sind Blockdiagramme von exemplarischen Computerarchitekturen. Andere auf dem Gebiet der Technik bekannte Systemausführungen und -konfigurationen für Laptops, Desktops, Handheld-PCs, PDAs, Engineering-Workstations, Server, Netzwerkgeräte, Netzwerk-Hubs, Switches, eingebettete Prozessoren, digitale Signalprozessoren (DSP), Grafikgeräte, Videospielgeräte, Set-top-Boxen, Mikrocontroller, Mobiltelefone, tragbare Medienspieler, Handheld-Geräte und verschiedene andere elektronische Vorrichtungen sind ebenfalls geeignet. Im Allgemeinen ist eine Vielzahl an Systemen oder elektronischen Vorrichtungen geeignet, die zum Integrieren eines Prozessors und/oder anderer Ausführungslogik wie hierin offenbart in der Lage sind.
  • Sich nun auf 12 beziehend, wird ein Blockdiagramm eines Systems 1200 gemäß einer Ausführungsform der vorliegenden Erfindung gezeigt. Das System 1200 kann einen oder mehrere Prozessoren 1210, 1215 umfassen, die mit einem Controller-Hub 1220 gekoppelt sind. In einer Ausführungsform umfasst der Controller-Hub 1220 einen Graphics Memory Controller Hub (GMCH) 1290 und einen Input/Output-Hub (IOH) 1250 (welche auf separaten Chips sein können); der GMCH 1290 umfasst Speicher- und Grafikcontroller, mit denen Speicher 1240 und ein Coprozessor 1245 gekoppelt sind; der IOH 1250 koppelt Eingabe-/Ausgabegeräte (E/A-Geräte) 1260 an den GMCH 1290. Alternativ sind einer oder beide Speicher- und Grafikcontroller in den Prozessor integriert (wie hierin beschrieben), der Speicher 1240 und der Coprozessor 1245 sind direkt mit dem Prozessor 1210 und dem Controller-Hub 1220 in einem einzigen Chip mit dem IOH 1250 gekoppelt.
  • Der optionale Charakter dieser zusätzlichen Prozessoren 1215 ist in 12 durch gestrichelte Linien gekennzeichnet. Jeder Prozessor 1210, 1215 kann einen oder mehrere der hierin beschriebenen Prozessorkerne umfassen und irgendeine Version des Prozessors 1100 sein.
  • Der Speicher 1240 kann beispielsweise dynamischer Direktzugriffsspeicher (DRAM), Phasenwechselspeicher (PCM) oder eine Kombination aus beiden sein. Bei zumindest einer Ausführungsform kommuniziert der Controller-Hub 1220 mit einem oder mehreren Prozessoren 1210, 1215 über einen Multidrop-Bus wie einen Front Side Bus (FSB), Punkt-zu-Punkt-Schnittstelle wie QuickPath Interconnect (QPI) oder ähnliche Verbindung 1295.
  • In einer Ausführungsform ist der Coprozessor 1245 ein Spezialprozessor wie beispielsweise ein Hochdurchsatz-MIC-Prozessor, ein Netzwerk- oder Kommunikationsprozessor, Kompressionsmechanismus, Grafikprozessor, GPGPU, eingebetteter Prozessor oder dergleichen. In einer Ausführungsform kann der Controller-Hub 1220 einen integrierten Grafikbeschleuniger umfassen.
  • Es kann eine Vielzahl an Unterschieden zwischen den physikalischen Ressourcen 1210, 1215 hinsichtlich eines Spektrums der Leistungsmetrik geben, einschließlich architektonische, mikroarchitektonische, thermale Eigenschaften, Leistungsbedarfseigenschaften und dergleichen.
  • In einer Ausführungsform führt der Prozessor 1210 Befehle aus, die Datenverarbeitungsoperationen allgemeiner Art steuern. In die Befehle können Coprozessorbefehle eingebettet sein. Der Prozessor 1210 erkennen diese Coprozessorbefehle als eine Art, die von dem angeschlossenen Coprozessor 1245 ausgeführt werden soll. Demgemäß erteilt der Prozessor 1210 diese Coprozessorbefehle (oder Steuersignale, die Coprozessorbefehle darstellen) auf einem Coprozessor-Bus oder einer anderen Verbindung an den Coprozessor 1245. Der oder die Coprozessoren 1245 akzeptieren die empfangenen Coprozessorbefehle und führen sie aus.
  • Sich nun auf 13 beziehend, wird ein Blockdiagramm eines ersten spezifischeren exemplarischen Systems 1300 gemäß einer Ausführungsform der vorliegenden Erfindung gezeigt. Wie in 13 gezeigt ist Multiprozessorsystem 1300 ein Punkt-zu-Punkt-Verbindungssystem und umfasst einen ersten Prozessor 1370 und einen zweiten Prozessor 1380, die über eine Punkt-zu-Punkt-Verbindung 1350 gekoppelt sind. Jeder der Prozessoren 1370 und 1380 kann irgendeine Version des Prozessors 1100 sein. In einer Ausführungsform der Erfindung sind die Prozessoren 1370 und 1380 jeweils die Prozessoren 1210 und 1215, während Coprozessor 1338 Coprozessor 1245 ist. In einer anderen Ausführungsform sind die Prozessoren 1370 und 1380 jeweils Prozessor 1210 und Coprozessor 1245.
  • Die Prozessoren 1370 und 1380 sind einschließlich integrierter Speichercontrollereinheiten (IMC) 1372 respektive 1382 gezeigt. Prozessor 1370 umfasst auch als Teil seiner Bus-Controller-Einheiten Punkt-zu-Punkt-(P-P)-Schnittstellen 1376 und 1378; gleichermaßen umfasst der zweite Prozessor 1380 P-P-Schnittstellen 1386 und 1388. Prozessoren 1370, 1380 können Informationen über eine Punkt-zu-Punkt-(P-P)-Schnittstelle 1350 unter Verwendung von P-P-Schnittstellenschaltungen 1378, 1388 austauschen. Wie in 13 gezeigt koppeln die integrierten Speichercontroller (IMC) 1372 und 1382 die Prozessoren an die jeweiligen Speicher, nämlich einen Speicher 1332 und einen Speicher 1334, welche Teile eines Hauptspeichers sein können, die lokal an die jeweiligen Prozessoren angeschlossen sind.
  • Die Prozessoren 1370, 1380 können jeweils Informationen mit einem Chipsatz 1390 über individuelle P-P-Schnittstellen 1352, 1354 unter Verwendung von P-P-Schnittstellenschaltungen 1376, 1394, 1386, 1398 austauschen. Der Chipsatz 1390 kann optional Informationen mit dem Coprozessor 1338 über eine Hochleistungsschnittstelle 1339 austauschen. In einer Ausführungsform ist der Coprozessor 1338 ein Spezialprozessor wie beispielsweise ein Hochdurchsatz-MIC-Prozessor, ein Netzwerk- oder Kommunikationsprozessor, Komprimierungsmechanismus, Grafikprozessor, GPGPU, eingebetteter Prozessor oder dergleichen.
  • Ein gemeinsamer Cache (nicht gezeigt) kann in jedem der Prozessoren oder außerhalb beider Prozessoren eingeschlossen werden, jedoch mit den Prozessoren über eine P-P-Verbindung verbunden, damit die lokalen Cache-Informationen von einem oder beiden der Prozessoren im gemeinsamen Cache gespeichert werden können, wenn ein Prozessor auf einen niedrigeren Leistungsmodus gesetzt wird.
  • Der Chipsatz 1390 kann über eine Schnittstelle 1396 mit einem ersten Bus 1316 gekoppelt werden. In einer Ausführungsform kann der erste Bus 1316 ein Bus zur Verbindung von Peripheriegeräten (PCI) oder ein Bus wie ein PCI-Express-Bus oder ein anderer E/A-Verbindungsbus dritter Generation sein, wenngleich der Schutzrahmen der vorliegenden Erfindung nicht so eingeschränkt ist.
  • Wie in 13 gezeigt können verschiedene E/A-Geräte 1314 mit dem ersten Bus 1316 gekoppelt werden, zusammen mit einer Busbrücke 1318, welche den ersten Bus 1316 an einen zweiten Bus 1320 koppelt. In einer Ausführungsform werden einer oder mehrere zusätzliche Prozessoren 1315, wie Coprozessoren, Hochdurchsatz-MIC-Prozessoren, GPGPUs, Beschleuniger (wie z. B. Grafikbeschleuniger oder digitale Signalprozessoreinheiten (DSP)), feldprogrammierbare Gatteranordnungen (Field Programmable Gate Arrays) oder irgendwelche andere Prozessoren, mit dem ersten Bus 1316 gekoppelt. In einer Ausführungsform kann der zweite Bus 1320 ein Low-Pin-Count-Bus (LPC) sein. Verschiedene Geräte können mit einem zweiten Bus 1320 gekoppelt werden, einschließlich in einer Ausführungsform beispielsweise eine Tastatur und/oder Maus 1322, Kommunikationsgeräte 1327 und eine Speichereinheit 1328 wie ein Laufwerk oder ein anderes Massenspeichergerät, das Befehle/Code und Daten 1330 umfassen kann. Ferner kann ein Audio-E/A 1324 mit dem zweiten Bus 1320 gekoppelt werden. Es ist festzuhalten, dass andere Architekturen möglich sind. Beispielweise kann ein System anstelle der Punkt-zu-Punkt-Architektur aus 13 einen Multi-Drop-Bus oder eine andere solche Architektur implementieren.
  • Sich nun auf 14 beziehend ist ein Blockdiagramm eines zweiten spezifischeren exemplarischen Systems 1400 gemäß einer Ausführungsform der vorliegenden Erfindung gezeigt. Gleiche Elemente in den 13 und 14 haben gleiche Referenzziffern, und gewisse Aspekte aus 13 wurden bei 14 ausgelassen, um eine Verzerrung anderer Aspekte aus 14 zu vermeiden.
  • 14 veranschaulicht, dass die Prozessoren 1370, 1380 integrierte Speicher- und E/A-Steuerungslogik (CL) 1372 respektive 1382 umfassen können. Folglich umfasst die Steuerungslogik 1372, 1382 integrierte Speichersteuerungseinheiten und E/A-Steuerungslogik. 14 veranschaulicht, dass nicht nur die Speicher 1332, 1334 mit der Steuerungslogik 1372, 1382 gekoppelt ist, sondern auch dass auch E/A-Geräte 1414 mit der Steuerungslogik 1372, 1382 gekoppelt sind. Alte E/A-Geräte 1415 sind mit dem Chipsatz 1390 gekoppelt.
  • Sich nun auf 15 beziehend ist ein Blockdiagramm eines Ein-Chip-Systems (SoC) 1500 gemäß einer Ausführungsform der vorliegenden Erfindung gezeigt. Ähnliche Elemente in 11 haben gleiche Referenzziffern. Außerdem sind Kästen mit gestrichelten Linien optionale Funktionen bei weiter fortgeschrittenen Ein-Chip-Systemen. In 15 sind eine oder mehrere Verbindungseinheiten 1502 gekoppelt mit: einem Anwendungsprozessor 1510, der eine Gruppe von einem oder mehreren Kernen 202A–N und eine oder mehrere gemeinsame Cache-Einheiten 1106 umfasst; einer Systemagenteneinheit 1110; einer oder mehreren Bus-Controller-Einheiten 1116; einer oder mehreren integrierten Speichercontroller-Einheiten 1114; einer Gruppe einer oder mehrerer Coprozessoren 1520, die integrierte Grafiklogik, einen Bildprozessor, einen Audioprozessor und einen Videoprozessor umfassen können; einer statischen Direktzugriffsspeichereinheit (SRAM) 1530; einer Direktzugriffsspeichereinheit (DMA) 1532; und einer Bildschirmeinheit 1540 zur Kopplung mit einem oder mehreren externen Bildschirmen. In einer Ausführungsform umfassen der oder die Coprozessoren 1520 einen Spezialprozessor wie beispielsweise einen Netzwerk- oder Kommunikationsprozessor, Komprimierungsmechanismus, GPGPU, Hochdurchsatz-MIC-Prozessor, eingebetteten Prozessor oder dergleichen.
  • Ausführungsformen der hierin offenbarten Mechanismen können in Hardware, Software, Firmware oder einer Kombination solcher Implementierungsansätze implementiert werden. Ausführungsformen der Erfindung können als Computerprogramme oder Programmcode, der auf programmierbaren Systemen ausgeführt wird, implementiert werden, die zumindest einen Prozessor, ein Speichersystem (einschließlich flüchtige und nichtflüchtige Speicher- und/oder Speicherungselemente), zumindest ein Eingabegerät und zumindest ein Ausgabegerät umfassen.
  • Programmcode wie Code 1330, der in 13 veranschaulicht wird, kann bei Eingabebefehlen eingesetzt werden, um die hierin beschriebenen Funktionen auszuführen und Ausgabeinformation zu generieren. Die Ausgabeinformation kann bei einem oder mehreren Ausgabegeräten auf die bekannte Art und Weise angewandt werden. Für die Zwecke dieser Patentanmeldung umfasst ein Prozessorsystem jedes System, das einen Prozessor hat, wie beispielsweise ein digitaler Signalprozessor (DSP), ein Mikrocontroller, eine anwendungsspezifische integrierte Schaltung (ASIC) oder ein Mikroprozessor.
  • Der Programmcode kann in einer höheren prozeduralen oder objektorientierten Programmiersprache implementiert werden, um mit einem Verarbeitungssystem zu kommunizieren. Der Programmcode kann, wenn gewünscht, auch in Assembler- oder Maschinensprache implementiert werden. Die hierin beschriebenen Mechanismen sind tatsächlich in ihrem Schutzumfang nicht auf eine besondere Programmiersprache eingeschränkt. In jedem Fall kann die Sprache eine kompilierte oder interpretierte Sprache sein.
  • Einer oder mehrere Aspekte von zumindest einer Ausführungsform können durch repräsentative Befehle, die auf einem maschinenlesbaren Medium gespeichert sind, das unterschiedliche Logik innerhalb des Prozessors darstellt, die, wenn sie von einer Maschine gelesen wird, die Maschine veranlasst, Logik zu schaffen, um die Verfahren wie hierin beschrieben durchzuführen. Solche Darstellungen, bekannt als „IP-Core”, können auf einem greifbaren, maschinenlesbaren Medium gespeichert werden und für verschiedene Kunden oder Produktionsstätten zum Laden in die Produktionsmaschinen, die tatsächlich die Logik oder den Prozessor herstellen, bereitgestellt werden.
  • Solche maschinenlesbaren Speichermedien können ohne Einschränkung nicht-transitorische, greifbare Artikelanordnungen umfassen, die von einer Maschine oder einer Vorrichtung hergestellt oder gebildet wurden, einschließlich Speichermedien wie Festplatten, jede andere Art von Platten einschließlich Disketten, optische Speicherplatten, CD-ROMs (Compact Disc Read-Only Memory), CD-RWs (Compact Disc ReWritable) und magnetoptische Disketten, Halbleiterspeicher wie Nur-Lese-Speicher (ROMs), Direktzugriffsspeicher (RAMs) wie dynamische Direktzugriffsspeicher (DRAMs), statische Direktzugriffsspeicher (SRAMs), löschbare programmierbare Nur-Lese-Speicher (EPROMs), Flash-Speicher, elektrisch löschbare programmierbare Nur-Lese-Speicher (EEPROMs), Phasenwechselspeicher (PCM), magnetische oder optische Karten oder jede andere Medienart, die zum Speichern elektronischer Befehle geeignet ist.
  • Demgemäß umfassen Ausführungsformen der Erfindung auch nicht-transitorische, greifbare maschinenlesbare Medien, die Befehle oder Designdaten enthalten, wie Hardwarebeschreibungssprache (HDL), die hierin beschriebene Strukturen, Schaltungen, Geräte, Prozessoren und/oder Systemfunktionen definiert. Solche Ausführungsformen können auch als Programmprodukte bezeichnet werden.
  • Emulation (einschließlich binäre Übersetzung, Code-Morphing etc.)
  • In manchen Fällen kann ein Befehlskonvertierer verwendet werden, um einen Befehl von einem Quellbefehlssatz in einen Zielbefehlssatz zu konvertieren. Beispielsweise kann der Befehlskonvertierer einen Befehl in einen oder mehrere vom Kern zu verarbeitende Befehle übersetzen (z. B. unter Verwendung von statischer binärer Übersetzung, dynamischer binärer Übersetzung einschließlich dynamischer Kompilierung), morphen, emulieren oder anders konvertieren. Der Befehlskonvertierer kann in Software, Hardware, Firmware oder eine Kombination daraus implementiert werden. Der Befehlskonvertierer kann auf dem Prozessor oder außerhalb des Prozessors sein, oder teilweise auf dem und teilweise außerhalb des Prozessors.
  • 16 ist ein Blockdiagramm, das die Verwendung eines Softwarebefehlskonvertierers zum Konvertieren binärer Befehle in einem Quellbefehlssatz in binäre Befehle in einem Zielbefehlssatz gemäß den Ausführungsformen der Erfindung gegenüberstellt. In der veranschaulichten Ausführungsform ist der Befehlskonvertierer ein Softwarebefehlskonvertierer, wenngleich der Befehlskonvertierer alternativ in Software, Firmware, Hardware oder verschiedenen Kombinationen daraus implementiert werden kann. 16 zeigt, dass ein Programm in höherer Sprache 1602 durch die Verwendung eines x86-Kompilierers 1604 kompiliert werden kann, um x86-Binärcode 1606 zu generieren, der durch einen Prozessor mit zumindest einem x86-Befehlssatzkern 1616 nativ ausgeführt werden kann. Der Prozessor mit zumindest einem x86-Befehlssatzkern 1616 stellt irgendeinen Prozessor dar, der im Wesentlichen dieselben Funktionen wie ein Intel-Prozessor mit zumindest einem x86-Befehlssatzkern ausführen kann, indem 1) ein wesentlicher Teil des Befehlssatzes des Intel-x86-Befehlssatzkerns oder 2) Objektcodeversionen von Anwendungen oder anderer Software, die darauf ausgerichtet ist, auf einem Intel-Prozessor mit zumindest einem x86-Befehlssatzkern zu laufen, kompatibel auszuführen oder anders zu verarbeiten, um im Wesentlichen das gleiche Ergebnis wie ein Intel-Prozessor mit zumindest einem x86-Befehlssatzkern zu erreichen. der x86-Kompilierer 1604 stellt einen Kompilierer dar, der betriebsfähig ist, x86-Binärcode 1606 (z. B. Objektcode) zu generieren, der mit oder ohne zusätzliche Verbindungsverarbeitung auf dem Prozessor mit zumindest einem x86-Befehlssatzkern 1616 ausgeführt werden kann. Gleichermaßen zeigt 16, dass das Programm in der höheren Sprache 1602 durch die Verwendung eines alternativen Befehlssatzkompilierers 1608 kompiliert werden kann, um alternativen Befehlssatzbinärcode 1610 zu generieren, der durch einen Prozessor ohne zumindest einen x86-Befehlssatzkern 1614 nativ ausgeführt werden kann (z. B. ein Prozessor mit Kernen, die den MIPS-Befehlssatz von MIPS Technologies, Sunnyvale, Kalifornien und/oder den ARM-Befehlssatz von ARM Holdings, Sunnyvale, Kalifornien ausführen). Der Befehlskonvertierer 1612 wird verwendet, um den x86-Binärcode 1606 in Code zu konvertieren, der von dem Prozessor ohne zumindest einen x86-Befehlssatzkern 1614 nativ ausgeführt werden kann. Dieser konvertierte Code ist wahrscheinlich nicht gleich wie der alternative Befehlssatzbinärcode 1610, da ein Befehlskonverter, der dazu in der Lage ist, schwierig herzustellen ist; der konvertierte Code wird jedoch den allgemeinen Betrieb durchführen und sich aus Befehlen vom alternativen Befehlssatz zusammensetzen. Folglich stellt der Befehlskonvertierer 1612 Software, Firmware, Hardware oder eine Kombination daraus dar, die durch Emulation, Simulation oder irgendeinen anderen Prozess einen Prozessor oder ein anderes elektronisches Gerät zulassen, das keinen x86-Befehlssatzprozessor oder -kern zur Ausführung des x86-Binärcodes 1606 hat.
  • Komponenten, Funktionen und Details, die in einer der 6–8 beschrieben werden, können auch optional in einer der 1–5 verwendet werden. Darüber hinaus können Komponenten, Funktionen und Details, die hierin für eines der hierin beschriebenen Geräte beschrieben werden, optional auch in einem der hierin beschriebenen Verfahren verwendet werden und/oder für sie gelten, die in Ausführungsformen durch und/oder mit solchen Geräten durchgeführt werden. Jeder der hierin beschriebenen Prozessoren kann in eines der Computersysteme oder andere hierin offenbarte Systeme eingeschlossen werden.
  • In der Beschreibung und den Ansprüchen können die Begriffe „gekoppelt” und/oder „verbunden” zusammen mit ihren Derivaten verwendet worden sein. Diese Begriffe sind nicht als Synonyme füreinander gedacht. Vielmehr kann in Ausführungsformen „verbunden” verwendet werden, um anzuzeigen, dass zwei oder mehr Elemente in direktem physischen und/oder elektrischen Kontakt zueinander sind. „Gekoppelt” kann bedeuten, dass zwei oder mehr Elemente in direktem physischen und/oder elektrischen Kontakt zueinander sind. „Gekoppelt” kann jedoch auch bedeuten, dass zwei oder mehr Elemente nicht in direktem Kontakt zueinander sind, aber dennoch trotzdem miteinander kooperieren oder interagieren. In den Figuren werden Pfeile verwendet, um Verbindungen und Kopplungen zu zeigen.
  • Es kann der Begriff „und/oder” verwendet worden sein. Wie hierin verwendet bedeutet der Begriff „und/oder” eines oder das andere oder beide (z. B. A und/oder B bedeutet A oder B oder sowohl A als auch B).
  • In der obenstehenden Beschreibung wurden spezifische Details dargelegt, um ein gründliches Verständnis der Ausführungsformen zu bieten. Es können jedoch andere Ausführungsformen ohne einige dieser spezifischen Details betrieben werden. Der Schutzrahmen der Erfindung ist nicht durch die oben genannten spezifischen Beispiele, sondern nur durch die Ansprüche unten festgelegt. Bei anderen Beispielen wurden wohlbekannte Schaltungen, Strukturen, Geräte und Operationen in Form eines Blockdiagramms und/oder ohne Details gezeigt, um eine Verzerrung des Verständnisses der Beschreibung zu vermeiden. Wo es geeignet erschien, wurden Referenzzahlen oder die letzten Teile der Referenzzahlen zwischen den Figuren wiederholt, um entsprechende oder analoge Elemente anzuzeigen, die optional ähnliche oder die gleichen Eigenschaften haben können, sofern es nicht spezifiziert ist oder anderweitig klar offensichtlich ist. In manchen Fällen, in denen mehrere Komponenten gezeigt und beschrieben wurden, können diese stattdessen gegebenenfalls optional miteinander als einzelne Komponente verbunden werden. In anderen Fällen, in denen eine einzelne Komponente gezeigt und beschrieben wurde, kann diese gegebenenfalls optional in zwei oder mehr Komponenten aufgeteilt werden.
  • Es wurden verschiedene Operationen und Verfahren beschrieben. Einige der Verfahren wurden in relativ grundlegender Form in den Flussdiagrammen beschrieben, aber Operationen können optional den Verfahren hinzugefügt werden und/oder daraus gelöscht werden. Wenngleich die Flussdiagramme eine gewisse Reihenfolge der Operationen gemäß den Ausführungsformen zeigen, ist diese Reihenfolge zudem exemplarisch. Andere Ausführungsformen können die Operationen in unterschiedlicher Reihenfolge ausführen, gewisse Operationen kombinieren, gewissen Operationen überschneiden etc.
  • Einige Ausführungsformen umfassen einen Produktionsartikel (z. B. ein Computerprogrammprodukt), das ein maschinenlesbares Medium umfasst. Das Medium kann einen Mechanismus umfassen, der Information in einer Form, die von der Maschine lesbar ist, bereitstellt, beispielsweise speichert. Das maschinenlesbare Medium kann eine Befehlssequenz bereitstellen oder darauf gespeichert haben, die, wenn sie und/oder während sie von einer Maschine ausgeführt wird, betriebsfähig ist, die Maschine zu veranlassen, eine oder mehrere hierin beschriebene Operationen, Verfahren oder Techniken auszuführen und/oder zur Ausführung durch die Maschine führt.
  • In manchen Ausführungsformen kann das maschinenlesbare Medium ein greifbares und/oder nicht-greifbares maschinenlesbares Speichermedium umfassen. Beispielsweise kann das greifbare und/oder nicht-greifbare maschinenlesbare Speichermedium eine Diskette, ein optisches Speichermedium, eine optische Speicherplatte, ein optisches Datenspeichergerät, eine CD-ROM, eine magnetische Diskette, eine magnetoptische Diskette, einen Nur-Lese-Speicher (ROM), einen programmierbaren Nur-Lese-Speicher (PROM), einen löschbaren programmierbaren Nur-Lese-Speicher (EPROM), einen elektrisch löschbaren programmierbaren Nur-Lese-Speicher (EEPROM), einen Direktzugriffsspeicher (RAM), einen statischen Direktzugriffsspeicher (SRAM), einen dynamischen Direktzugriffsspeicher (DRAM), einen Flash-Speicher, einen Phasenwechselspeicher, ein Phasenwechseldatenspeichermaterial, ein nichtflüchtiger Speicher, ein nichtflüchtiges Datenspeichergerät, ein nicht-transitorischer Speicher, ein nicht-transitorisches Datenspeichergerät oder dergleichen. Das nicht-transitorische maschinenlesbare Speichermedium besteht nicht aus einem transitorischen propagierten Signal.
  • Beispiele geeigneter Maschinen umfassen, sind aber nicht darauf beschränkt, Computergeräte oder anderen elektronische Geräte, die einen oder mehrere Prozessoren umfassen. Beispiele solcher Computergeräte und elektronischer Geräte umfassen, sind aber nicht darauf beschränkt, Mobiltelefone, Smartphones, Tabletcomputer, Netbooks, mobile Internetgeräte (MIDs), Medienspieler, Laptop-Computer, Notebook-Computer, Desktopcomputer, Smart-TVs, Nettops, Set-top-Boxen und Videospielcontroller, um nur einige Beispiele zu nennen.
  • Bezugnahme in dieser Beschreibung auf beispielsweise „eine Ausführungsform”, „Ausführungsform”, „eine oder mehrere Ausführungsformen”, „einige Ausführungsformen” zeigt an, dass eine gewisse Funktion in die Durchführung der Erfindung inkludiert werden kann, das aber nicht notwendigerweise erforderlich ist. Gleichermaßen werden in der Beschreibung verschiedene Funktionen manchmal in einer einzigen Ausführungsform, Figur oder Beschreibung davon zusammengefasst, um die Offenbarung zu vereinfachen und das Verständnis verschiedener Aspekte der Erfindung zu fördern. Dieses Verfahren der Offenbarung soll jedoch nicht so ausgelegt werden, dass es die Intention widerspiegelt, dass die Erfindung mehr Funktionen erfordert, als in jedem Anspruch ausdrücklich erwähnt werden. Wie die folgenden Ansprüche zeigen, liegen Aspekte der Erfindung in weniger als allen Funktionen einer einzelnen offenbarten Ausführungsform. Folglich werden die Ansprüche, die der detaillierten Beschreibung folgen, hierdurch ausdrücklich in diese detaillierte Beschreibung aufgenommen, wobei jeder Anspruch für sich allein als eine separate Ausführungsform der Erfindung steht.
  • BEISPIELHAFTE AUSFÜHRUNGSFORMEN
  • Die folgenden Beispiele betreffen weitere Ausführungsformen. Spezifika in den Beispielen können überall in einen oder mehreren Ausführungsformen verwendet werden.
  • Beispiel 1 umfasst ein architekturübergreifendes Kompatibilitätsgerät, das ein Kontrollflusstransferempfangsmodul umfasst, um eine erste Prozeduraufrufoperation von einem Codemodul erster Architektur zu empfangen, die für ein Bibliotheksmodul erster Architektur bestimmt ist. Die erste Prozeduraufrufoperation bezieht eine erste Vielzahl an Eingabeparametern ein. Ein ABI-Änderungsmodul ist mit dem Kontrollflusstransferempfangsmodul gekoppelt. Das ABI-Änderungsmodul macht ABI-Änderungen, um die erste Prozeduraufrufoperation, die die erste Vielzahl an Eingabeparametern einbezieht, in eine entsprechende zweite Prozeduraufrufoperation, die eine zweite Vielzahl an Eingabeparametern einbezieht, zu konvertieren. Die zweite Prozeduraufrufoperation ist mit einem Bibliotheksmodul zweiter Architektur kompatibel. Ein Kontrollflusstransferausgabemodul ist mit dem ABI-Änderungsmodul gekoppelt. Das Kontrollflusstransferausgabemodul stellt dem Bibliotheksmodul zweiter Architektur die zweite Prozeduraufrufoperation bereit.
  • Beispiel 2 umfasst das Gerät nach Beispiel 1, in dem das ABI-Änderungsmodul einen ersten Parameter der ersten Vielzahl an Eingabeparametern von einem Stapel empfängt, und einen zweiten Parameter der zweiten Vielzahl an Eingabeparametern, der dem ersten Parameter entspricht, in einem Register speichert, von dem erwartet wird, dass es für den zweiten Parameter von dem Bibliotheksmodul zweiter Architektur verwendet wird.
  • Beispiel 3 umfasst das Gerät nach Beispiel 1, in dem das Kontrollflusstransferempfangsmodul, das ABI-Änderungsmodul und das Kontrollflusstransferausgabemodul Teil eines ersten Wrapper-Moduls sind, das dem Bibliotheksmodul erster Architektur entspricht.
  • Beispiel 4 umfasst das Gerät nach Beispiel 3, das zusätzlich eine Vielzahl an Wrapper-Modulen enthält, die jeweils einem unterschiedlichen Bibliotheksmodul erster Architektur entsprechen, in dem jedes der Vielzahl an Wrapper-Modulen ein Kontrollflusstransferempfangsmodul, ein ABI-Änderungsmodul und ein Kontrollflusstransferausgabemodul hat.
  • Beispiel 5 umfasst das Gerät nach Beispiel 4, in dem das erste Wrapper-Modul den gleichen Namen wie das Bibliotheksmodul erster Architektur hat, und in dem jedes der Vielzahl an Wrapper-Modulen den gleichen Namen wie das entsprechende unterschiedliche Bibliotheksmodul erster Architektur hat.
  • Beispiel 6 umfasst das Gerät nach Beispiel 1, das zusätzlich ein Prozessormodus-Änderungsmodul enthält, um eine auszuführende Codeart, die von einem Code erster Architektur und einem Code zweiter Architektur ausgewählt wird, zu ermitteln, wobei das Prozessormodus-Änderungsmodul einen Codeart-Ausführungsmodus eines Prozessors ändert, um mit der ermittelten auszuführenden Codeart kompatibel zu sein.
  • Beispiel 7 umfasst das Gerät nach Beispiel 6, in dem das Prozessormodus-Änderungsmodul die auszuführende Codeart basierend auf intersegmentären Kontrollflusstransfers zwischen einem ersten Segment, das den gesamten Code erster Architektur hat, und einem zweiten Segment, das den gesamten Code zweiter Architektur hat, ermittelt.
  • Beispiel 8 umfasst das Gerät nach einem der Beispiele 1 bis 7, in dem das Kontrollflusstransferempfangsmodul die erste Prozeduraufrufoperation, die für ein 32-Bit-Bibliotheksmodul bestimmt ist, von einem 32-Bit-Codemodul empfängt, in dem das ABI-Änderungsmodul die erste Prozeduraufrufoperation zu der entsprechenden zweiten Prozeduraufrufoperation, die mit einem 64-Bit-Bibliotheksmodul kompatibel ist, konvertiert, und in dem das Kontrollflusstransferausgabemodul die zweite Prozeduraufrufoperation für das 64-Bit-Bibliotheksmodul bereitstellt.
  • Beispiel 9 umfasst das Gerät nach einem der Beispiele 1 bis 7, in dem eine maximale Bit-Breite von Architekturganzzahlregistern, die vom Codemodul erster Architektur verwendet werden kann, sich von einer maximalen Bit-Breite von Architekturganzzahlregistern, die vom Codemodul zweiter Architektur verwendet werden kann, unterscheidet.
  • Beispiel 10 ist ein architekturübergreifendes Kompatibilitätsverfahren, das den Empfang einer ersten Prozeduraufrufoperation, die für ein Bibliotheksmodul erster Architektur bestimmt ist, von einem Codemodul erster Architektur umfasst. Die erste Prozeduraufrufoperation bezieht eine erste Vielzahl an Eingabeparametern ein. Das Verfahren umfasst auch das Bereitstellen einer entsprechenden zweiten Prozeduraufrufoperation, die eine zweite Vielzahl an Eingabeparametern umfasst, für ein Bibliotheksmodul zweiter Architektur.
  • Beispiel 11 umfasst das Verfahren nach Beispiel 10, in welchem der Empfang den Empfang der ersten Prozeduraufrufoperation, die für ein 32-Bit-Bibliotheksmodul bestimmt ist, von einem 32-Bit-Codemodul umfasst, und in welchem das Bereitstellen das Bereitstellen der zweiten Prozeduraufrufoperation an ein 64-Bit-Bibliotheksmodul umfasst.
  • Beispiel 12 umfasst das Verfahren nach Beispiel 10, das zusätzlich den Empfang eines ersten Parameters der ersten Vielzahl an Eingabeparametern von einem Stapel und das Speichern eines zweiten Parameters der zweiten Vielzahl an Eingabeparametern, wobei der zweite Parameter dem ersten Parameter entspricht, in einem Register, das das Bibliotheksmodul zweiter Architektur verwendet hat, um den zweiten Parameter zu empfangen, umfasst.
  • Beispiel 13 umfasst das Verfahren nach Beispiel 10, in dem der Empfang den Empfang der ersten Prozeduraufrufoperation mit einem Wrapper-Modul, das den gleichen Namen wie das Bibliotheksmodul erster Architektur hat, umfasst.
  • Beispiel 14 umfasst das Verfahren nach Beispiel 13, das zusätzlich die Konfiguration des Wrapper-Moduls umfasst, um von einem dynamischen Linker sowohl vor dem Bibliotheksmodul erster Architektur als auch vor dem Bibliotheksmodul zweiter Architektur gesucht zu werden.
  • Beispiel 15 umfasst das Verfahren nach Beispiel 10, das in einer elektrischen Vorrichtung durchgeführt wird, die das Bibliotheksmodul erster Architektur nicht besitzt.
  • Beispiel 16 ist ein Computersystem, das einen Speicher umfasst, um ein 32-Bit-Codemodul und ein 64-Bit-Bibliotheksmodul zu speichern. Ein 64-Bit-Prozessor ist mit dem Speicher gekoppelt. Das System umfasst auch ein architekturübergreifendes Kompatibilitätsmodul, um eine Prozeduraufrufoperation von einem 32-Bit-Codemodul für ein 32-Bit-Bibliotheksmodul abzufangen, und um eine entsprechende Prozeduraufrufoperation für das 64-Bit-Bibliotheksmodul bereitzustellen.
  • Beispiel 17 umfasst das Computersystem nach Beispiel 16, in dem das architekturübergreifende Kompatibilitätsmodul ABI-Änderungen macht, um die Prozeduraufrufoperation für das 32-Bit-Bibliotheksmodul in die entsprechende Prozeduraufrufoperation für das 64-Bit-Bibliotheksmodul zu konvertieren.
  • Beispiel 18 umfasst das Computersystem nach Beispiel 16, in dem das 32-Bit-Codemodul und das 64-Bit-Bibliotheksmodul in unterschiedlichen Segmenten im Speicher gespeichert werden und in dem ein Segment, das das 32-Bit-Codemodul speichert, flache Adressierung verwendet.
  • Beispiel 19 umfasst das Computersystem nach Beispiel 16, in dem das architekturübergreifende Kompatibilitätsmodul ein Wrapper-Modul mit dem gleichen Namen wie das 32-Bit-Bibliotheksmodul umfasst, das die Prozeduraufrufoperation von dem 32-Bit-Codemodul abfängt.
  • Beispiel 20 umfasst das Computersystem nach einem der Beispiele 16 bis 19, in dem das Computersystem das 32-Bit-Bibliotheksmodul nicht besitzt.
  • Beispiel 21 umfasst das Computersystem nach Beispiel 20, in dem das Computersystem keine 32-Bit-Bibliotheksmodule besitzt.
  • Beispiel 22 umfasst das Computersystem nach einem der Beispiele 16 bis 19, in dem das Computersystem ein Smartphone umfasst.
  • Beispiel 23 ist ein Produktionsartikel, der ein nicht-transitorisches maschinenlesbares Speichermedium umfasst, das Befehle speichert, die, wenn sie von einer Maschine ausgeführt werden, die Maschine veranlassen, Operationen durchzuführen, die den Empfang einer ersten Prozeduraufrufoperation, die für ein Bibliotheksmodul erster Architektur bestimmt ist, von einem Codemodul erster Architektur umfassen, wobei die erste Prozeduraufrufoperation eine erste Vielzahl an Eingabeparametern beinhaltet. Die Operationen umfassen auch das Vornehmen von ABI-Änderungen, um die erste Prozeduraufrufoperation, die die erste Vielzahl an Eingabeparametern beinhaltet, in eine entsprechende zweite Prozeduraufrufoperation, die eine zweite Vielzahl an Eingabeparametern beinhaltet, zu konvertieren. Die Operationen umfassen auch das Bereitstellen der zweiten Prozeduraufrufoperation für ein Bibliotheksmodul zweiter Architektur.
  • Beispiel 24 umfasst den Produktionsartikel nach Beispiel 23, in dem die Befehle, wenn sie von einer Maschine ausgeführt werden, die Maschine veranlassen, Operationen durchzuführen, die den Empfang einer ersten Prozeduraufrufoperation, die für ein 32-Bit-Bibliotheksmodul bestimmt ist, von einem 32-Bit-Codemodul und das Bereitstellen der zweiten Prozeduraufrufoperation für ein 64-Bit-Bibliotheksmodul umfassen.
  • Beispiel 25 umfasst den Produktionsartikel nach einem der Beispiele 23 bis 24, die zusätzlich Befehle speichern, die, wenn sie von einer Maschine ausgeführt werden, die Maschine veranlassen, Operationen durchzuführen, die den Empfang eines ersten Parameters aus der ersten Vielzahl an Eingabeparametern von einem Stapel und das Speichern eines zweiten Parameters aus der zweiten Vielzahl an Eingabeparametern, wobei der zweite Parameter dem ersten Parameter entspricht, in einem Register, das vom Bibliotheksmodul zweiter Architektur für den Empfang des zweiten Parameters verwendet wurde, umfassen.
  • Beispiel 26 umfasst ein Gerät, das betriebsfähig ist, das Verfahren nach einem der Beispiele 10–15 durchzuführen.
  • Beispiel 27 umfasst ein Gerät einschließlich der Mittel, um die Verfahren nach einem der Beispiele 10–15 durchzuführen.
  • Beispiel 28 umfasst ein Gerät einschließlich Module, Einheiten, Mittel oder einer Kombination daraus, um das Verfahren nach einem der Beispiele 10–15 durchzuführen.
  • Beispiel 29 umfasst einen Produktionsartikel, das ein optional nicht-transitorisches maschinenlesbares Speichermedium umfasst, das optional Befehle speichert oder anders bereitstellt, die wenn sie und/oder während sie von einem Prozessor, Computersystem oder einer anderen Maschine ausgeführt werden, betriebsfähig sind, das Computersystem oder die andere Maschine zu veranlassen, das Verfahren nach einem der Beispiele 10–15 durchzuführen.
  • Beispiel 30 umfasst ein Computersystem oder eine andere elektronische Vorrichtung, die einen Bus oder andere Verbindungsgeräte, einen mit dem Verbindungsgerät gekoppelten Prozessor, einen mit dem Verbindungsgerät gekoppelten Flash-Speicher und eine optionale mit dem Verbindungsgerät gekoppelte Antenne umfasst, wobei das Computersystem oder die andere elektronische Vorrichtung betriebsfähig ist, das Verfahren nach einem der Beispiele 10–15 durchzuführen.
  • Beispiel 31 umfasst ein Gerät, das betriebsfähig ist, eine oder mehrere Operationen oder ein Verfahren im Wesentlichen wie hierin beschrieben durchzuführen.
  • Beispiel 32 umfasst ein architekturübergreifendes Kompatibilitätsmodul im Wesentlichen wie hierin beschrieben.

Claims (25)

  1. Architekturübergreifendes Kompatibilitätsgerät, umfassend: ein Kontrollflusstransferempfangsmodul für den Empfang einer ersten Prozeduraufrufoperation, die für ein Bibliotheksmodul erster Architektur bestimmt ist, von einem Codemodul erster Architektur, wobei die erste Prozeduraufrufoperation eine erste Vielzahl an Eingabeparametern einbezieht; ein Binärschnittstellenänderungsmodul (ABI-Änderungsmodul), das mit dem Kontrollflusstransferempfangsmodul gekoppelt ist, wobei das ABI-Änderungsmodul ABI-Änderungen macht, um die erste Prozeduraufrufoperation, die die erste Vielzahl an Eingabeparametern einbezieht, in eine entsprechende zweite Prozeduraufrufoperation, die eine zweite Vielzahl an Eingabeparametern einbezieht und die mit einem Bibliotheksmodul zweiter Architektur kompatibel ist, zu konvertieren; und ein Kontrollflusstransferausgabemodul, das mit dem ABI-Änderungsmodul gekoppelt ist, wobei das Kontrollflusstransferausgabemodul die zweite Prozeduraufrufoperation für das Bibliotheksmodul zweiter Architektur bereitstellt.
  2. Gerät nach Anspruch 1, worin das ABI-Änderungsmodul: einen ersten Parameter aus der ersten Vielzahl an Eingabeparametern von einem Stapel empfangt; und einen zweiten Parameter aus der zweiten Vielzahl an Eingabeparametern, der dem ersten Parameter entspricht, in einem Register speichert, von dem erwartet wird, dass es für den zweiten Parameter von dem Bibliotheksmodul zweiter Architektur verwendet wird.
  3. Gerät nach Anspruch 1 oder 2, worin das Kontrollflusstransferempfangsmodul, das ABI-Änderungsmodul und das Kontrollflusstransferausgabemodul Teil eines ersten Wrapper-Moduls sind, das dem Bibliotheksmodul erster Architektur entspricht.
  4. Gerät nach Anspruch 3, das ferner eine Vielzahl an Wrapper-Modulen umfasst, die alle einem unterschiedlichen Bibliotheksmodul erster Architektur entsprechen, worin jedes aus der Vielzahl an Wrapper-Modulen ein Kontrollflusstransferempfangsmodul, ein ABI-Änderungsmodul und ein Kontrollflusstransferausgabemodul aufweist.
  5. Gerät nach Anspruch 4, worin das erste Wrapper-Modul einen gleichen Namen wie das Bibliotheksmodul erster Architektur aufweist und worin jedes aus der Vielzahl an Wrapper-Modulen einen gleichen Namen wie das entsprechende unterschiedliche Bibliotheksmodul erster Architektur aufweist.
  6. Gerät nach einem der Ansprüche 1 bis 5, das ferner ein Prozessormodus-Änderungsmodul umfasst, um eine auszuführende Codeart zu ermitteln, die von einem Code erster Architektur und einem Code zweiter Architektur ausgewählt wird, wobei das Prozessormodus-Änderungsmodul einen Codeart-Ausführungsmodus eines Prozessors ändert, um mit der ermittelten auszuführenden Codeart kompatibel zu sein.
  7. Gerät nach Anspruch 6, worin das Prozessormodus-Änderungsmodul die auszuführende Codeart ermittelt, basierend auf intersegmentären Kontrollflusstransfers zwischen einem ersten Segment, das den gesamten Code erster Architektur hat, und einem zweiten Segment, das den gesamten Code zweiter Architektur hat.
  8. Gerät nach einem der Ansprüche 1 bis 7, worin das Kontrollflusstransferempfangsmodul die erste Prozeduraufrufoperation, die für ein 32-Bit-Bibliotheksmodul bestimmt ist, von einem 32-Bit-Codemodul empfängt, worin das ABI-Änderungsmodul die erste Prozeduraufrufoperation in die entsprechende zweite Prozeduraufrufoperation, die mit einem 64-Bit-Bibliotheksmodul kompatibel ist, konvertiert, und worin das Kontrollflusstransferausgabemodul die zweite Prozeduraufrufoperation für das 64-Bit-Bibliotheksmodul bereitstellt.
  9. Gerät nach einem der Ansprüche 1 bis 8, worin eine maximale Bit-Breite von Architekturganzzahlregistern, die zur Verwendung durch das Codemodul erster Architektur in der Lage sind, sich von einer maximalen Bit-Breite von Architekturganzzahlregistern, die zur Verwendung durch das Codemodul zweiter Architektur in der Lage sind, unterscheidet und worin das Bibliotheksmodul zweiter Architektur von einem Mathematikbibliotheksmodul und einem C-Standardbibliotheksmodul ausgewählt wird.
  10. Architekturübergreifendes Kompatibilitätsverfahren, umfassend: den Empfang einer ersten Prozeduraufrufoperation, die für ein Bibliotheksmodul erster Architektur bestimmt ist, von einem Codemodul erster Architektur, wobei die erste Prozeduraufrufoperation eine erste Vielzahl an Eingabeparametern einbezieht; und das Bereitstellen einer entsprechenden zweiten Prozeduraufrufoperation, die eine zweite Vielzahl an Eingabeparametern umfasst, für ein Bibliotheksmodul zweiter Architektur.
  11. Verfahren nach Anspruch 10, worin der Empfang den Empfang einer ersten Prozeduraufrufoperation, die für ein 32-Bit-Bibliotheksmodul bestimmt ist, von einem 32-Bit-Codemodul umfasst und worin das Bereitstellen das Bereitstellen von der zweiten Prozeduraufrufoperation an ein 64-Bit-Bibliotheksmodul umfasst.
  12. Verfahren nach Anspruch 10 oder 11, ferner umfassend: den Empfang eines ersten Parameters aus der ersten Vielzahl an Eingabeparametern von einem Stapel; und das Speichern eines zweiten Parameters aus der zweiten Vielzahl an Eingabeparametern, wobei der zweite Parameter dem ersten Parameter entspricht, in einem Register, das das Bibliotheksmodul zweiter Architektur verwendet hat, um den zweiten Parameter zu empfangen.
  13. Verfahren nach einem der Ansprüche 10 bis 12, worin der Empfang den Empfang einer ersten Prozeduraufrufoperation mit einem Wrapper-Modul, das einen gleichen Namen wie das Bibliotheksmodul erster Architektur aufweist, umfasst.
  14. Verfahren nach Anspruch 13, die ferner die Konfiguration des Wrapper-Moduls umfasst, um von einem dynamischen Linker sowohl vor dem Bibliotheksmodul erster Architektur als auch vor dem Bibliotheksmodul zweiter Architektur gesucht zu werden.
  15. Verfahren nach einem der Ansprüche 10 bis 14, durchgeführt in einem elektronischen Gerät, welches das Bibliotheksmodul erster Architektur nicht aufweist.
  16. Computersystem, umfassend: einen Speicher, um ein 32-Bit-Codemodul und ein 64-Bit-Bibliotheksmodul zu speichern; einen 64-Bit-Prozessor, der mit dem Speicher gekoppelt ist; und ein architekturübergreifendes Kompatibilitätsmodul, um eine Prozeduraufrufoperation von dem 32-Bit-Codemodul für ein 32-Bit-Bibliotheksmodul abzufangen und eine entsprechende Prozeduraufrufoperation für das 64-Bit-Bibliotheksmodul bereitzustellen.
  17. Computersystem nach Anspruch 16 oder 17, worin das architekturübergreifende Kompatibilitätsmodul Binärschnittstellenänderungen (ABI-Änderungen) macht, um die Prozeduraufrufoperation für das 32-Bit-Bibliotheksmodul in die entsprechende Prozeduraufrufoperation für das 64-Bit-Bibliotheksmodul zu konvertieren.
  18. Computersystem nach Anspruch 16 oder 17, worin das 32-Bit-Codemodul und das 64-Bit-Bibliotheksmodul in unterschiedlichen Segmenten des Speichers gespeichert werden und worin ein Segment, das das 32-Bit-Codemodul speichert, flache Adressierung verwendet.
  19. Computersystem nach einem der Ansprüche 16 bis 18, worin das architekturübergreifende Kompatibilitätsmodul ein Wrapper-Modul mit einem gleichen Namen wie das 32-Bit-Bibliotheksmodul umfasst, das die Prozeduraufrufoperation vom 32-Bit-Codemodul abfängt.
  20. Computersystem nach einem der Ansprüche 16 bis 19, worin das Computersystem das 32-Bit-Bibliotheksmodul nicht aufweist.
  21. Produktionsartikel, der ein nicht-transitorisches maschinenlesbares Speichermedium umfasst, das Befehle speichert, die, wenn sie von einer Maschine ausgeführt werden, die Maschine zum Durchführen von Operationen veranlasst, einschließlich: Empfang einer ersten Prozeduraufrufoperation, die für ein Bibliotheksmodul erster Architektur bestimmt ist, von einem Codemodul erster Architektur, wobei die erste Prozeduraufrufoperation eine erste Vielzahl an Eingabeparametern umfasst; Durchführen von Binärschnittstellenänderungen (ABI-Änderungen), um die erste Prozeduraufrufoperation, die die erste Vielzahl an Eingabeparametern einbezieht, in eine zweite Prozeduraufrufoperation, die eine zweite Vielzahl an Eingabeparametern einbezieht, zu konvertieren; und Bereitstellen der zweiten Prozeduraufrufoperation für ein Bibliotheksmodul zweiter Architektur.
  22. Produktionsartikel nach Anspruch 21, worin die Befehle, wenn sie von der Maschine ausgeführt werden, die Maschine zum Durchführen von Operationen veranlassen, einschließlich: Empfang der ersten Prozeduraufrufoperation, die für ein 32-Bit-Bibliotheksmodul bestimmt ist, von einem 32-Bit-Codemodul; und Bereitstellen der zweiten Prozeduraufrufoperation für ein 64-Bit-Bibliotheksmodul.
  23. Gerät, das Mittel umfasst, das Verfahren nach einem der Ansprüche 10 bis 15 durchzuführen.
  24. Produktionsartikel, der ein nicht-transitorisches maschinenlesbares Medium umfasst, das Befehle speichert, die, wenn sie von einer Maschine ausgeführt werden, entscheidend sind, um die Maschine zur Durchführung des Verfahrens nach einem der Ansprüche 10 bis 15 zu veranlassen.
  25. Architekturübergreifendes Kompatibilitätsgerät, umfassend: Mittel für den Empfang einer ersten Prozeduraufrufoperation, die für ein Bibliotheksmodul erster Architektur bestimmt ist, von einem Codemodul erster Architektur, wobei die erste Prozeduraufrufoperation eine erste Vielzahl an Eingabeparametern einbezieht; und Mittel für das Bereitstellen einer entsprechenden zweiten Prozeduraufrufoperation, die eine zweite Vielzahl an Eingabeparametern einbezieht, für ein Bibliotheksmodul zweiter Architektur.
DE102015002582.1A 2014-03-28 2015-02-27 Architekturübergreifendes Kompatibilitätsmodul, um zuzulassen, dass ein Codemodul einer Architektur ein Bibliotheksmodul einer anderen Architektur verwendet Pending DE102015002582A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US14/229,795 US10120663B2 (en) 2014-03-28 2014-03-28 Inter-architecture compatability module to allow code module of one architecture to use library module of another architecture
US14/229,795 2014-03-28

Publications (1)

Publication Number Publication Date
DE102015002582A1 true DE102015002582A1 (de) 2015-10-01

Family

ID=52630760

Family Applications (1)

Application Number Title Priority Date Filing Date
DE102015002582.1A Pending DE102015002582A1 (de) 2014-03-28 2015-02-27 Architekturübergreifendes Kompatibilitätsmodul, um zuzulassen, dass ein Codemodul einer Architektur ein Bibliotheksmodul einer anderen Architektur verwendet

Country Status (7)

Country Link
US (1) US10120663B2 (de)
JP (1) JP6124463B2 (de)
KR (1) KR101817397B1 (de)
CN (1) CN104951296B (de)
DE (1) DE102015002582A1 (de)
GB (1) GB2524616B (de)
TW (1) TWI567646B (de)

Families Citing this family (40)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9851987B2 (en) * 2012-03-22 2017-12-26 Intel Corporation Nested emulation and dynamic linking environment
US9958932B2 (en) * 2014-11-20 2018-05-01 Apple Inc. Processor including multiple dissimilar processor cores that implement different portions of instruction set architecture
US9477490B2 (en) * 2015-01-05 2016-10-25 Dell Software Inc. Milestone based dynamic multiple watchdog timeouts and early failure detection
US9778945B2 (en) * 2015-02-10 2017-10-03 Red Hat Israel, Ltd. Providing mode-dependent virtual machine function code
US11403099B2 (en) * 2015-07-27 2022-08-02 Sony Interactive Entertainment LLC Backward compatibility by restriction of hardware resources
US9928115B2 (en) 2015-09-03 2018-03-27 Apple Inc. Hardware migration between dissimilar cores
WO2017052555A1 (en) * 2015-09-24 2017-03-30 Hewlett Packard Enterprise Development Lp Process and thread launch features
US10452409B2 (en) * 2015-10-23 2019-10-22 Oracle International Corporation Universal adapter for native calling
US9753776B2 (en) * 2015-12-01 2017-09-05 International Business Machines Corporation Simultaneous multithreading resource sharing
US10284592B1 (en) 2015-12-17 2019-05-07 Architecture Technology Corporation Application randomization mechanism
US10200401B1 (en) * 2015-12-17 2019-02-05 Architecture Technology Corporation Evaluating results of multiple virtual machines that use application randomization mechanism
US10412114B1 (en) 2015-12-17 2019-09-10 Architecture Technology Corporation Application randomization mechanism
US10007498B2 (en) 2015-12-17 2018-06-26 Architecture Technology Corporation Application randomization mechanism
US10412116B1 (en) 2015-12-17 2019-09-10 Architecture Technology Corporation Mechanism for concealing application and operation system identity
US10853118B2 (en) * 2015-12-21 2020-12-01 Intel Corporation Apparatus and method for pattern-driven page table shadowing for graphics virtualization
US10261921B2 (en) * 2016-02-19 2019-04-16 Rajnarine Brigmohan Universal secure platform virtualization system and method thereof
US10303488B2 (en) * 2016-03-30 2019-05-28 Sony Interactive Entertainment Inc. Real-time adjustment of application-specific operating parameters for backwards compatibility
US10853040B2 (en) 2017-03-31 2020-12-01 Microsoft Technology Licensing, Llc Address space splitting for legacy application compatibility
CN107423084B (zh) * 2017-04-24 2021-02-02 武汉斗鱼网络科技有限公司 程序修改方法及装置
US10554685B1 (en) 2017-05-25 2020-02-04 Architecture Technology Corporation Self-healing architecture for resilient computing services
US11275587B2 (en) * 2018-05-02 2022-03-15 Micron Technology, Inc. Static identifications in object-based memory access
US10761855B2 (en) 2018-05-02 2020-09-01 Micron Technology, Inc. Securing conditional speculative instruction execution
US10977101B2 (en) 2018-12-12 2021-04-13 International Business Machines Corporation Interoperability between programs associated with different addressing modes
US11249760B2 (en) 2019-04-10 2022-02-15 International Business Machines Corporation Parameter management between programs
EP3748440B1 (de) * 2019-06-03 2023-11-08 ABB Schweiz AG Arbeitsablauf einer vorrichtung
CN112083934A (zh) * 2019-06-13 2020-12-15 青岛海信移动通信技术股份有限公司 一种终端和处理方法
CN111026452B (zh) * 2019-11-20 2023-10-20 北京明朝万达科技股份有限公司 一种远程32位进程注入64位进程的方法及系统
CN111142969A (zh) * 2019-12-27 2020-05-12 贵阳动视云科技有限公司 64位程序调用32位程序模块的方法、装置、介质及设备
US11294695B2 (en) * 2020-05-28 2022-04-05 International Business Machines Corporation Termination of programs associated with different addressing modes
CN113760338B (zh) * 2020-06-05 2023-07-18 北京字跳网络技术有限公司 切换应用程序二进制接口abi的方法、装置及电子设备
US11403100B2 (en) * 2020-08-31 2022-08-02 Microsoft Technology Licensing, Llc Dual architecture function pointers having consistent reference addresses
US11231918B1 (en) 2020-08-31 2022-01-25 Microsoft Technologly Licensing, LLC Native emulation compatible application binary interface for supporting emulation of foreign code
CN112486570B (zh) * 2020-11-06 2023-06-02 麒麟软件有限公司 一种不同类型CPU的Glibc兼容方法
EP4053722B1 (de) 2021-03-01 2023-11-29 Irdeto B.V. Sicherer computercode und systeme, verfahren und speichermedien zur erzeugung des sicheren computercodes aus originalem computercode
US12014198B2 (en) 2021-03-25 2024-06-18 International Business Machines Corporation Running smaller memory-address width program code in a larger memory-address width address space
CN113076263A (zh) * 2021-05-06 2021-07-06 北京字节跳动网络技术有限公司 一种进程运行的方法、装置、计算机设备及存储介质
US11947993B2 (en) 2021-06-22 2024-04-02 International Business Machines Corporation Cooperative input/output of address modes for interoperating programs
US11556356B1 (en) 2021-09-23 2023-01-17 International Business Machines Corporation Dynamic link objects across different addressing modes
CN114510267B (zh) * 2022-04-20 2023-03-21 麒麟软件有限公司 基于Linux系统的程序ABI接口兼容性计算方法
US12028224B1 (en) 2023-02-17 2024-07-02 International Business Machines Corporation Converting an architecture document to infrastructure as code

Family Cites Families (47)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5604885A (en) 1991-02-01 1997-02-18 Texas Instruments Incorporated Apparatus and method enabling a computer to transfer control between two program segments that call one another but operate in different modes
US5379432A (en) * 1993-07-19 1995-01-03 Taligent, Inc. Object-oriented interface for a procedural operating system
US5473777A (en) * 1993-07-19 1995-12-05 Moeller; Christopher P. Wrapper for enabling an object otented application to maintain virtual memory using procedural function calls
US6438621B1 (en) 1994-11-14 2002-08-20 Microsoft Corporation In-memory modification of computer programs
US5870587A (en) 1996-03-20 1999-02-09 International Business Machines Corporation Information-handling system, method, and article of manufacture including a mechanism for providing an improved application binary interface
US5845107A (en) 1996-07-03 1998-12-01 Intel Corporation Signaling protocol conversion between a processor and a high-performance system bus
US8065504B2 (en) * 1999-01-28 2011-11-22 Ati International Srl Using on-chip and off-chip look-up tables indexed by instruction address to control instruction execution in a processor
US8127121B2 (en) 1999-01-28 2012-02-28 Ati Technologies Ulc Apparatus for executing programs for a first computer architechture on a computer of a second architechture
JP3762867B2 (ja) * 1999-01-29 2006-04-05 富士通株式会社 コンパイラ装置、コンパイル方法、およびそのためのプログラムを格納した記憶媒体
US6715063B1 (en) 2000-01-14 2004-03-30 Advanced Micro Devices, Inc. Call gate expansion for 64 bit addressing
US6662361B1 (en) 2000-01-14 2003-12-09 International Business Machines Corporation Method, system, program, and data structures for transforming an instruction in a first bit architecture to an instruction in a second bit architecture
US6725366B1 (en) * 2000-09-07 2004-04-20 International Business Machines, Corporation System and method for 32 bit code branching to 64 bit targets
US7406681B1 (en) * 2000-10-12 2008-07-29 Sun Microsystems, Inc. Automatic conversion of source code from 32-bit to 64-bit
GB0026363D0 (en) * 2000-10-27 2000-12-13 Sgs Thomson Microelectronics Bi-endian libraries
US7406682B2 (en) * 2001-03-26 2008-07-29 Emc Corporation Translator-compiler for converting legacy management software
AT411044B (de) 2001-10-16 2003-09-25 Burg Design Gmbh Dekorelement
US7020729B2 (en) 2002-05-16 2006-03-28 Intel Corporation Protocol independent data transmission interface
US7124445B2 (en) * 2002-06-21 2006-10-17 Pace Anti-Piracy, Inc. Protecting software from unauthorized use by converting source code modules to byte codes
US7353502B2 (en) * 2002-07-03 2008-04-01 The Mathworks, Inc. System and method for creation of software components
US8423976B2 (en) 2003-03-13 2013-04-16 Northrop Grumman Corporation Extreme pipeline and optimized reordering technology
GB0316531D0 (en) 2003-07-15 2003-08-20 Transitive Ltd Method and apparatus for performing native binding
US7519951B2 (en) * 2003-09-30 2009-04-14 International Business Machines Corporation Multi-attribute dynamic link library packaging
US20050221813A1 (en) 2004-04-05 2005-10-06 Jarno Rajahalme System and method for initiating auxiliary communication interfaces via a primary communication interface
US7634768B2 (en) * 2005-02-17 2009-12-15 Intel Corporation Methods and apparatus to support mixed-mode execution within a single instruction set architecture process of a virtual machine
US7966624B2 (en) * 2007-08-22 2011-06-21 Intel Corporation Using message passing interface (MPI) profiling interface for emulating different MPI implementations
US8832679B2 (en) * 2007-08-28 2014-09-09 Red Hat, Inc. Registration process for determining compatibility with 32-bit or 64-bit software
US20090144046A1 (en) 2007-09-28 2009-06-04 Rothman Michael A Method to encapsulate an option rom for operation in multiple firmware and platform architectures
US7831813B2 (en) 2007-12-17 2010-11-09 Globalfoundries Inc. Uses of known good code for implementing processor architectural modifications
JP4352086B2 (ja) * 2007-12-21 2009-10-28 株式会社東芝 情報処理装置およびオペレーティングシステム判別方法
US20100077378A1 (en) * 2008-09-25 2010-03-25 International Business Machines Corporation Virtualised Application Libraries
US9189620B2 (en) * 2009-06-30 2015-11-17 Intel Corporation Protecting a software component using a transition point wrapper
US8561183B2 (en) * 2009-07-31 2013-10-15 Google Inc. Native code module security for arm instruction set architectures
US8645936B2 (en) * 2009-09-30 2014-02-04 Zynga Inc. Apparatuses, methods and systems for an a API call abstractor
CA2776913C (en) * 2009-10-08 2017-01-03 Irdeto Canada Corporation A system and method for aggressive self-modification in dynamic function call systems
US9075688B2 (en) * 2010-02-09 2015-07-07 Accenture Global Services Limited Enhanced upgrade path
KR101211673B1 (ko) 2010-12-08 2012-12-12 한국과학기술연구원 사용자 단말에서 다른 시스템 환경을 갖는 외부 단말의 프로그램을 실행하기 위한 바이너리 호환 시스템 및 그 방법
US20120222024A1 (en) * 2011-02-24 2012-08-30 Kushal Das Mechanism for Managing Support Criteria-Based Application Binary Interface/Application Programming Interface Differences
US9891939B2 (en) 2011-03-03 2018-02-13 Microsoft Technology Licensing, Llc Application compatibility with library operating systems
CN103092599A (zh) 2011-11-05 2013-05-08 京瓷办公信息系统株式会社 软件开发套件
CN104137055B (zh) * 2011-12-29 2018-06-05 英特尔公司 点积处理器、方法、系统和指令
KR101691063B1 (ko) * 2012-01-10 2016-12-29 인텔 코포레이션 콜백을 이용하는 isa 브리징
US9063759B2 (en) * 2012-03-28 2015-06-23 International Business Machines Corporation Optimizing subroutine calls based on architecture level of called subroutine
RU2012127581A (ru) * 2012-07-02 2014-01-10 ЭлЭсАй Корпорейшн Генератор исходного кода для разработки и тестирования программного обеспечения для многопроцессорных сред
WO2014022980A1 (en) 2012-08-08 2014-02-13 Intel Corporation Isa bridging including support for call to overidding virtual functions
US20140282371A1 (en) * 2013-03-14 2014-09-18 Media Direct, Inc. Systems and methods for creating or updating an application using a pre-existing application
WO2014172710A1 (en) 2013-04-19 2014-10-23 The Trustees Of Columbia University In The City Of New York Methods, systems, and media for binary compatibility
US9424420B2 (en) * 2013-08-02 2016-08-23 Red Hat, Inc. Restricting application binary interfaces

Also Published As

Publication number Publication date
KR101817397B1 (ko) 2018-01-11
US20150277867A1 (en) 2015-10-01
GB2524616B (en) 2018-05-09
JP6124463B2 (ja) 2017-05-10
GB2524616A (en) 2015-09-30
KR20150112778A (ko) 2015-10-07
CN104951296B (zh) 2019-02-15
US10120663B2 (en) 2018-11-06
JP2015191657A (ja) 2015-11-02
TWI567646B (zh) 2017-01-21
CN104951296A (zh) 2015-09-30
GB201500818D0 (en) 2015-03-04
TW201545058A (zh) 2015-12-01

Similar Documents

Publication Publication Date Title
DE102015002582A1 (de) Architekturübergreifendes Kompatibilitätsmodul, um zuzulassen, dass ein Codemodul einer Architektur ein Bibliotheksmodul einer anderen Architektur verwendet
DE112017001825T5 (de) Prozessoren, verfahren, systeme und instruktionen zum atomischen speichern von daten, die breiter als eine nativ unterstützte datenbreite sind, in einem speicher
DE112013004751T5 (de) Prozessor mit mehreren Kernen, gemeinsam genutzter Kernerweiterungslogik und gemeinsam genutzten Kernerweiterungsnutzungsbefehlen
DE102015006863A1 (de) Befehle und Logik zum Unterbrechen und Wiederaufnehmen von Paging in Secure Enclaves
DE112016004960T5 (de) Befehl und logik, um informationen im voraus aus einem beständigen speicher zu holen
DE102014003671A1 (de) Prozessoren, verfahren und systeme zum entspannen der synchronisation von zugriffen auf einen gemeinsam genutzten speicher
DE102014003690A1 (de) Prozessoren, Verfahren und Systeme zur Befehlsemulation
DE102014003795A1 (de) Verfahren und Vorrichtungen für Fusionsbefehle zur Bereitstellung der OR-Test- und AND-Test-Funktionalität auf mehreren Testquellen
DE112017001700T5 (de) Prozessoren, Verfahren, Systeme und Anweisungen zum Abruf von Daten auf der angegebenen Cache-Ebene mit garantiertem Abschluss
DE102018132521A1 (de) Vorrichtung und verfahren zur verflachung und reduktion von schleifen in einer single instruction, multiple data- (simd-) pipeline
DE102014003563A1 (de) Fusionierbare befehle und logik zum versehen mit or-test- und and-test-funktionalität unter benutzen von mehrfachtestquellen
DE102013021221A1 (de) Befehle und Logik zur Vektorisierung von bedingten Schleifen
DE112017001716T5 (de) Speicherkopierbefehle, prozessoren, verfahren und systeme
DE112013004867T5 (de) Befehl und Logik zum Bereitstellen von Push-Puffer-Kopier- und Speicher-Funktionalität
DE112013003731T5 (de) Neue befehls- und hocheffiziente Mikroarchitektur zum ermöglichen einer sofortigen Kontextumschaltung für Benutzerebenen-Threading
DE112012007058T5 (de) Vektormaskengesteuertes Clock-Gating für Leistungseffizenz eines Prozessors
DE112012007088B4 (de) Vorrichtung, verfahren und system mit einem befehl zum reduzieren von elementen in einem vektorregister mit einem schrittweisem zugriffsmuster
DE102014003705A1 (de) Prozessoren, Verfahren und Systeme zur Befehlsemulation
DE102014004564A1 (de) Prozessoren, verfahren und systeme zum implementieren von teilregisterzugriffen mit maskierten gesamtregisterzugriffen
DE112019002389T5 (de) Architektur zur dynamischen umwandlung einer speicherkonfiguration
DE102018130225A1 (de) Entfernte atomare Operationen in Multi-Sockel-Systemen
DE102018006537A1 (de) Dynamische Leistungsbeeinflussung in einem Prozessor
DE112013007702T5 (de) Befehl und Logik für den Speicherzugriff in einer geclusterten Maschine mit breiter Ausführung
DE112013004800T5 (de) Anweisung zur Bitverschiebung nach links mit Ziehen von Einsen in niedrigwertigere Bit
DE112017003345T5 (de) Bit-prüfprozessoren, verfahren, systeme und anweisungen zum prüfen eines bits mit einem angegebenen prüfbitwert

Legal Events

Date Code Title Description
R012 Request for examination validly filed
R016 Response to examination communication