-
Urheberrechtshinweis
-
Ein Teil der Offenbarung dieses Dokuments enthält Material, welches dem Urheberrecht unterliegt. Der Urheberrechts-Inhaber hat keinerlei Einwände bezüglich der originalgetreuen Kopie, durch irgendjemanden, der Patentschrift oder der Patentoffenbarung, wie sie in der Akte oder den Akten des Patent- und Markenamtes erscheint, behält sich jedoch jegliche Urheberrechte vor.
-
Hintergrund
-
Viele Programmiersprachen stellen, umfassend grafische Programmiersprachen und textuelle Programmiersprachen, Unterstützung für dynamisch typisiertes und Array-basiertes Programmieren bereit. Array-basierte Sprachen können zur Lösung vieler unterschiedlicher mathematischer und wissenschaftlicher Berechnungsprobleme verwendet werden. Beispiele von Berechnungsumgebungen, die dynamisch typisierte Matrix-basierte mathematische Programmiersprachen verwenden, sind Julia, Pyhton und die Matlab- und Simscape-Software von The MathWorks, Inc., Natick, Massachusetts.
-
In einer dynamisch typisierten Programmierumgebung ("DTPE") können Datentypen jedem Datenwert im Speicher während der Laufzeit zugewiesen werden, anstatt einen Typen zu einer statischen, syntaktischen Entität in dem Programmquellcode zuzuweisen. Die DTPE kann Fehler finden, die mit der falschen Verwendung von Werten in Beziehung stehen, wenn die fehlerhafte Anweisung oder der Ausdruck ausgeführt wird. Demgegenüber können in einer statisch typisierten Programmierumgebung ("STPE") können Typen Mengen von Werten, Programmvariablen und Ausdrücken, basierend auf dem Quellcode des Programms, zugewiesen werden. Statisch typisierte Disziplinen können auf Programmquellcode arbeiten statt auf der Programmausführung. Deshalb können in der STPE bestimmte Arten von Fehlern detektiert werden, ohne das Programm auszuführen.
-
Dynamisch typisierte Programmiersprachen ("DTPLs") können auf numerischen Arrays, zum Beispiel Vektoren und Matrizen, Zeichenarrays, Zellarrays und Arrays von Objekten arbeiten. Numerische Arrays und Zeichenarrays umfassen nur homogene Daten. Zellarrays, welche Programmierkonstrukte sind, die indizierte Datencontainer haben, die Zellen genannt werden, können jegliche Daten von jedem Typ und jeder Größe enthalten, die durch die Datenverarbeitungssoftware unterstützt werden. Beispiele von unterschiedlichen Datentypen können umfassen: logische Daten, Zeichendaten, verschiedene Typen von numerischen Daten (z.B. numerische skalare Daten und numerische Arrays), andere Zellarrays, Strukturen, Java-Klassen, Funktion-Handles und jedwede neue Datentypen, die durch eine objektorientierte Klassendefinition erstellt werden (z.B. jedwede neue Datentypen, die durch die Verwendung des MathLab-Objektsystems erstellt sind, wie z.B. MathLab oops, udd und mcos-Objektsystemen). Zellarrays von DTPLs können momentan nicht direkt in statisch typisierten Programmiersprachen ("STPL") repräsentiert werden.
-
Zusammenfassung
-
In einer Ausführungsform wird ein computerlesbares Medium bereitgestellt, welches von einem Prozessor ausführbare Instruktionen zur Erzeugung von Programmcode enthält. Wenn die Instruktionen durch einen oder mehrere Prozessoren ausgeführt werden, können die Instruktionen den einen oder die mehreren Prozessoren veranlassen, ein Computer-implementiertes Verfahren zur Erzeugung von zweitem Programmcode in einer statisch typisierten Programmiersprache aus erstem Programmcode in einer dynamisch typisierten Programmiersprache auszuführen. Der erste Programmcode kann ein dynamisch typisiertes Array aufweisen oder, wenn er ausgeführt wird, generieren oder auf diesem arbeiten. Das dynamisch typisierte Array kann in eine von mehreren Kategorien klassifiziert werden, basierend auf den Array-Inhalten, Array-Verwendungen oder Benutzereingaben. Der zweite Programmcode in der statisch typisierten Programmiersprache kann basierend auf dem Klassifizieren erzeugt werden. Die mehreren Kategorien können homogene, heterogene, Tabellen oder andere Klassifikationen umfassen. Der erste Programmcode kann analysiert werden, um zu bestimmen, ob Indexwerte, die verwendet werden, um in das eine oder die mehreren dynamisch typisierten Arrays zu indizieren, konstant sind und während der Ausführung des ersten Programmcodes konstant bleiben und Verwenden dieser Indexwerte, die konstant sind, um die Klassifizierung zu unterstützen.
-
In einer anderen Ausführungsform kann das Klassifizieren das Auswählen von einer oder mehreren Klassifikationsregeln aus einer Menge zur Anwendung vorgesehener Regeln umfassen, basierend auf einer Leistungspräferenz für den zweiten Programmcode und/oder basierend auf einer visuellen Lesbarkeitspräferenz für den zweiten Programmcode. Das Verfahren kann ein Zuweisen zu dem dynamisch typisierten Array nach einer homogenen oder heterogenen Klassifikation von Benutzereingaben, die jedweden automatischen Klassifikationsvorgang nichtig machen, der durch den einen oder die mehreren Prozessoren ausgeführt wurde, umfassen.
-
In noch einer weiteren Ausführungsform kann das Verfahren zur Erzeugung von Programmcode das Erzeugen einer Zwischenrepräsentation von dem ersten Programmcode und Ändern der Zwischenrepräsentation, basierend auf der Klassifikation, umfassen. Eine dynamisch typisierte Zwischenrepräsentation des ersten Programmcodes kann erzeugt werden, welche in eine statisch typisierte Zwischenrepräsentation umgewandelt wird. Die statisch typisierte Zwischenrepräsentation kann in den zweiten Programmcode in einer statisch typisierten Programmiersprache umgewandelt werden.
-
In einer weiteren Ausführungsform kann das dynamisch typisierte Array in eine statisch typisierte Zwischenrepräsentation, z.B. in ein Array, eine Struktur oder eine statisch typisierte Elemente umfassende Hash-Tabellendatenstruktur umgewandelt werden. Konstantenweitergabe oder Vereinfachung konstanter Teile zur Unterstützung der Umwandlung des ersten Programmcodes, der auf dem dynamisch typisierten Array arbeitet, in die statisch typisierte Zwischenrepräsentation kann verwendet werden. Funktionsspezialisierung, Schleifenabrollen und/oder Typunifikation können zur Unterstützung der Umwandlung des ersten Programmcodes, der auf dem dynamisch typisierten Array arbeitet, in die statisch typisierte Zwischenrepräsentation, verwendet werden.
-
In noch einer weiteren Ausführungsform umfasst das Erzeugen des zweiten Programmcodes das Bestimmen eines statischen Datentyps für jedes dynamisch typisierte Array und anschließend Verwenden des bestimmten Typs zur Unterstützung der Erzeugung des zweiten Programmcodes. Eine Typ-Inferenztechnik kann angewendet werden, um Typen für jedes dynamisch typisierte Array zu bestimmen. Der zweite Programmcode kann eine Repräsentation von dem einen oder den mehreren dynamisch typisierten Arrays umfassen und, wenn das zweite Programm ausgeführt wird, kann die Repräsentation im Speicher des Computers keinerlei Metadaten enthalten.
-
In noch einer weiteren Ausführungsform wird ein System zur Erzeugung von Programmcode bereitgestellt, umfassend einen oder mehrere Prozessoren, die dazu konfiguriert sind, zweiten Programmcode in einer statisch typisierten Programmiersprache aus erstem Programmcode in einer dynamisch typisierten Programmiersprache, zu erzeugen, wobei der erste Programmcode ein dynamisch typisiertes Array aufweist oder, wenn er ausgeführt wird, generiert oder auf diesem arbeitet. Der eine oder die mehreren Prozessoren können den zweiten Programmcode durch Klassifizieren des dynamisch typisierten Arrays in einer von mehreren Kategorien, basierend auf Array-Inhalten, Array-Verwendungen oder Benutzereingaben, erzeugen und den zweiten Programmcode in der statisch typisierten Programmiersprache, basierend auf dem Klassifizieren, erzeugen. Das System kann einen Speicher zur Speicherung der ersten und zweiten Programmcodes und eine Anzeigevorrichtung umfassen.
-
Kurze Beschreibung der Figuren
-
Die vorhergegangenen und andere Merkmale der Implementierungen werden durch die folgende, konkretere Beschreibung von beispielhaften Ausführungsformen der Implementierungen deutlich, wie durch die beigefügten Figuren veranschaulicht, in denen gleiche Bezugszeichen im Allgemeinen identische, funktional ähnliche und/oder strukturell ähnliche Elemente in verschiedenen Ansichten angeben. Die Figuren sind nicht notwendigerweise maßstabsgetreu, wobei der Schwerpunkt auf der Veranschaulichung der Prinzipien der Ausführungsformen liegt, wobei:
-
1 ein beispielhaftes Blockdiagramm ist, welches eine Umgebung zur Ausführung der veranschaulichenden Ausführungsform ist;
-
2 ein Schaubild einer beispielhaften Berechnungsumgebung ist, in der Vorrichtungen und/oder Verfahren, wie hierin beschrieben, implementiert werden können;
-
3 ein Schaubild einer beispielhaften verteilten Berechnungsumgebung ist, in der Vorrichtungen und/oder Verfahren, wie hierin beschrieben, implementiert werden können;
-
4 ein Flussdiagramm einer Beispielimplementierung eines Verfahrens zur Codeerzeugung ist; und
-
5 eine Veranschaulichung von beispielhaften heterogenen und homogenen Zellarrays ist.
-
Detaillierte Beschreibung
-
Die folgende detaillierte Beschreibung von Beispielimplementierungen bezieht sich auf die beiliegenden Figuren, wie oben angegeben.
-
I. Überblick
-
1 ist ein Blockdiagramm 100, welches auf einer allgemeinen Ebene eine beispielhafte Ausführungsform von Verfahren und Vorrichtungen zur Erzeugung von Programmcode 102 in einer STPL von Eingabeprogrammcode 104 in einer DTPL, umfassend eine oder mehrere dynamisch typisierte Arrays 106, veranschaulicht. In einigen Implementierungen umfasst der Programmcode 104 nicht explizit irgendwelche dynamisch typisierten Arrays, sondern erzeugt oder arbeitet auf einem oder mehreren dynamisch typisierten Arrays 106, wenn der Programmcode 104 ausgeführt wird. Die Eingabe 104 kann erzeugt oder als Benutzereingabe von einer Berechnungsumgebung als Programmquellcode oder in einer anderen dynamisch typisierten Form, erhalten werden. Ein Code-Generator 108 kann eine funktionale Komponente umfassen, die als ein Zwischenrepräsentationsbuilder (IR-Builder) 110 dargestellt wird, der eine IR für den empfangenen Programmcode 104 erzeugt. Die erzeugte IR kann eine dynamisch typisierte Zwischenrepräsentation (DTIR) 111 sein. Der Code-Generator 108 kann auch eine Typ-Inferenz Engine 114 umfassen, die das eine oder die mehreren Arrays 106, die mit dem Programmcode 104 assoziiert sind basierend auf der IR und unter Verwendung einer Menge von Klassifikationsregeln 116 in Klassen klassifiziert, die eine homogene Klasse, eine heterogene Klasse oder andere umfassen. Basierend auf der Klassifikation ändert ein IR-Modifizierer und/oder ein IR-Optimierer 118 die IR 111, die durch den IR-Builder 110 erzeugt wurde, und produziert somit eine statisch typisierte Zwischenrepräsentation (STIR) 112. Ein statisch typisierter Programmgenerator 120 erzeugt statisch typisierten Programmcode 102 unter Verwendung der modifizierten IR 112 für den Eingabeprogrammcode 104. Der statisch typisierte Programmcode 102 kann ein oder mehrere statisch typisierte Arrays 122 umfassen, die zu dem einen oder den mehreren dynamisch typisierten Arrays 106 korrespondieren, oder wenn er ausgeführt wird, ein oder mehrere statisch typisierte Arrays 122 erzeugen kann. Zusätzlich kann der Code-Generator 108 auch Hilfstransformationen 124 umfassen, die mit jedem der IR-Builder 110, der Typ-Inferenz-Engine 114, dem IR-Modifizierer und/oder -Optimierer 118 und dem statisch typisierten Programmgenerator 120 interagieren. Die Hilfstransformationen 124 können die Anwendbarkeit der Klassifikation und Zwischenrepräsentation auf reale Programme verbessern. Der Fachmann wird zu schätzen wissen, dass die folgende Beschreibung nicht den Umfang der Offenbarung dahingehend einschränken soll, dass alle funktionalen Komponenten und/oder Regeln in einer einzigen Einheit an einem einzigen Ort angeordnet sind. Zum Beispiel würden verteilte Berechnungsimplementierungen erlauben, dass die Klassifikationsregeln 116, die Transformationen 124 und/oder eine andere der Funktionen entfernt gespeichert und dass auf diese nach Bedarf zugegriffen werden wird. Der Code-Generator 108 muss nicht alle Teile und Funktionen enthalten, die in den Figuren dargestellt sind. Einige der Teile/Funktionen können außerhalb des Code-Generators bereitgestellt werden.
-
Der IR-Builder 110 kann die Klassifikation(en) der dynamisch typisierten Arrays 106 verwenden, um eine dynamisch typisierte Zwischenrepräsentation (DTIR) 111 von Programmcode 104 in eine STIR 112 umzuwandeln. Die Zwischenrepräsentationen erlauben das Durchführen von Übersetzungsaufgaben, die mit der Umwandlung von dynamisch typisiertem Programmcode 104 in statisch typisierten Programmcode 102 in diskreten Phasen assoziiert sind. Die DTIR und STIR modellieren individuelle Verhaltensweisen, wie Anwendungsmuster, die für die Zellarrays relevant sind, die assoziiert sind mit oder die in den entsprechenden Quell- und Zielprogrammiersprachen relevant sind.
-
In einigen Implementierungen kann das Übersetzen von Programmcode 104 in eine STIR durch Techniken ausgeführt werden, umfassend: Erstellen von Zwischenrepräsentationen (IRs), Verändern und/oder optimieren der IRs oder Anwenden von statischer Typ-Inferenz auf die (modifizierten/optimierten) IRs. Solche Technologien sind in Werkzeugen eingearbeitet, umfassend den MatLab Coder mit seiner Typ-Inferenz-Engine, die Stateflow-Zustands-basierte Flussdiagrammumgebung (integriert mit Simulink) und/oder der Realzeit-Workshop-Coder, die jeweils von The MathWorks, Natick, Massachusetts angeboten werden und die zur Modellierung komplexen Verhaltens unter Verwendung von endlichen Zustandsautomaten, Flussdiagramm-Notationen und Zustandsübergangstabellen nützlich sind. Zum Beispiel kann der Übersetzungsprozess Schritte zur Identifizierung von bestimmten Konstrukt- oder Array-Zugriffsmustern 106 in dem Programmcode 104 und Repräsentieren des Konstrukt- oder Zugriffsmusters in einer DTIR umfassen, zum Beispiel als ein Knoten oder Pfad in einem Steuer und/oder Datenflussgraphen. Der Programmcode 104 kann in eine STIR 112 umgewandelt werden, zum Beispiel in der die Konstrukt- oder Zugriffsmuster durch Repräsentationen repräsentiert werden, die die Syntax und/oder Regeln der Zielprogrammiersprache erfüllen und die dieselbe Struktur oder dasselbe Verhalten aufweisen. Die Übersetzung in die STIR kann automatisch ausgeführt werden und/oder mit Merkmalen ausgelöst werden, die auf Grundlage von Präferenzen oder Zielsetzungen ausgewählt werden, die mit dem Programmcode in Beziehung stehen, z.B. jene, die in der Eingabe 126 enthalten sind. Die Informationen, die in der STIR enthalten sind, können zur anschließenden Erzeugung von statisch typisiertem Programmcode 102 in der Zielsprache verwendet werden.
-
Der statisch typisierte Programmgenerator 120 kann die STIR in Programmcode 102 übersetzen, der in einer STPL geschrieben ist, die ein statisch typisiertes Array 122 oder eine statisch typisierte Struktur oder eine statisch typisierte Hash-Tabelle umfasst oder, wenn er ausgeführt wird, erzeugt, die zu dem dynamisch typisierten Array 106 korrespondieren. Der Ausgabeprogrammcode 102 kann durch einen externen Compiler verwendet werden, um ausführbaren Code für Hardware oder weitere Verarbeitung zu erzeugen. Der Fachmann wird einsehen, dass eine Vielzahl von Quell-DTPLs und Ziel-STPLs auf Grundlage der Bedürfnisse des Benutzers eingesetzt werden können.
-
Beispielhafte Implementierungen, wie unten beschrieben, stellen Verfahren und Vorrichtungen zur automatischen Übersetzung von dynamisch typisierten Array-basiertem Programmcode 104 zur Verfügung, der durch das Verwenden von einer von einer Vielzahl von Quell-DTPLs erstellt wurde, die Zellarrays oder äquivalente dynamische Datentypen verwenden, wie z.B. Julia, Pyhton, MatLab und Simscape, in Programmcode 102, umfassend Arrays, Strukturen und Hash-Tabellen in einer STPL, wie z.B. C, C++ und HDL, und/oder in STIRs, die zur Übersetzung in solche Sprachen geeignet sind. In einigen Implementierungen werden Zellarrays verwendet, um Eigenschaften/Wertepaare, Arrays von Datenzeichenketten, Arrays von Matrizen unterschiedlicher Größe, z.B. mit demselben Basistyp, Sammlungen von Objekten von unterschiedlichen Typen, Arrays von Arrays oder Arrays variabler Größe von Strukturen mit variablen Feldgrößen. Die Zellarrays können explizit in dem Programmcode 104 enthalten sein oder können durch den Programmcode 104 erzeugt werden, wenn die Eingabe ausgeführt wird. In einigen Implementierungen wird eine Klassifikationssyntax angewendet, die die Zellarray- und Mathematik-orientierte Eigenschaft einer DTPL ausnutzt. Der Code-Generator 108 kann auf einem oder mehreren Prozessoren implementiert sein, die Instruktionen zur Klassifizierung von Arrays und zur Übersetzung von Programmcode 104 in Programmcode 102, basierend auf der Klassifikation, ausführen und optional auch Instruktionen zur Erfüllung von einer oder mehreren Code-Qualitäts-Vorgaben oder anderer Präferenzen ausführen.
-
II. Beispielhafte Programmiersprache & Berechnungsumgebung
-
2 zeigt ein Blockdiagramm einer beispielhaften Berechnungsvorrichtung 200, die verwendet werden kann, um das System und die Verfahren der vorliegenden Offenbarung zu implementieren. Die Berechnungseinrichtung 200 kann einen Hauptprozessor (CPU) 202 (der mit einem einzelnen Prozessor, einem Mehrkernprozessor oder mehreren Prozessoren bestückt sein kann), einem Hauptspeicher 204, einer Benutzerschnittstelle 206, einer Festplatte 208 und einem Laufwerk für austauschbare Medien 210 umfassen, die durch einen Systembus 212 miteinander verbunden sind. Die CPU 202 steuert eine oder mehrere andere Komponenten der Berechnungseinrichtung 200, um Eingaben, die in einer dynamisch typisierten Sprache vorliegen, in statisch typisierten Programmcode zu übersetzen. Die Berechnungseinrichtung 200 kann auch eine Netzwerkschnittstellenkarte (NIC) 214 umfassen. Die Benutzerschnittstelle 206 kann eine Tastatur 216, eine Maus 218 und andere Eingabevorrichtungen sowie eine Anzeige 220 umfassen. Die Berechnungsvorrichtung kann durch eine der Eingabevorrichtungen Daten empfangen, die zur Erstellung von Leistungskriterien oder anderen Präferenzen für den Ausgabeprogrammcode 102 notwendig sind. In einigen Implementierungen können die Kriterien oder die Präferenzen als Optionen auf der Anzeige 220 angezeigt werden. Jeder Prozessor der CPU 202 kann ein 32 Bit-Prozessor, 64 Bit-Prozessor oder ein Prozessor anderen Typs sein, der in der Lage ist, Instruktionen auszuführen, die für die vorliegende Implementierung notwendig sind. Beispiele anderer Prozessoren können umfassen einen Grafikprozessor (GPU) oder anwendungsspezifische Hardware, die programmierbar ist (Field Programmable Gate Array), die auf eine Anwendungsdomäne zugeschnitten ist (location specific instruction set processor) oder spezifisch für eine Anwendung designed ist (application specific integrated circuit). Andere Berechnungsressourcen, wie Hardware-Beschleuniger, können zusätzlich verwendet werden, um die allgemeine Ausführungsrate der Berechnungsvorrichtung 200 zu erhöhen.
-
Der Speicher 204 kann eine Vielzahl von Modulen umfassen, wie z.B. ein Betriebssystem 222, eine Software-Entwicklungsumgebung 224, eine Eingabedatei 226, die z.B. zur Speicherung einer Ausführungsform von Programmcode 104 und einer Ausführungsform von dem Code-Generator 108 verwendet werden kann. Das Laufwerk für austauschbare Medien 210 kann dazu konfiguriert sein, ein nichtflüchtiges computerlesbares Medium 230 zu lesen, wie z.B. eine CD, DVD, Diskette, Flash-Speicher oder ein anderes Medium, welches Computer-ausführbare Instruktionen speichert. Das Laufwerk für austauschbare Medien 210 kann ferner dazu konfiguriert sein, auf das computerlesbare Medium 230 zu schreiben. Angemessene Betriebssysteme 222 umfassen die Windows-Serie von Betriebssystemen von Microsoft Corp. aus Redmont, Washington, das Linux-Betriebssystem und die Unix-Betriebssysteme sowie weitere.
-
Ein Benutzer kann die Tastatur 216, die Maus 218 und die Anzeige 220 der Benutzerschnittstelle 206 verwenden, um mit der Softwareentwicklungsumgebung 224 zu interagieren und die Eingabedatei 226 zu erstellen. Zum Zwecke der Veranschaulichung wird eine Reihe von Beispielen hierin mit Bezug auf MatLab oder Simscape beschrieben, die Array-basierte DTPLs von The MathWorks, Incorporated, Natick, Massachusetts sind. Es sollte geschätzt werden, dass diese Sprachen lediglich als Beispiele von DTPLs (andere umfassen Julia, Python, etc.) ausgewählt wurden und die Implementierungen sollten nicht dahingehend interpretiert werden, als dass sie auf diese beschränkt sind. Es sollte auch geschätzt werden, dass die Verwendung von Mengennotation in einigen Implementierungen, wie hierin besprochen, auf andere textuelle und grafische Programmiersprachen, wie z.B. die Unified Modeling Language (UML) und die System Modeling Language (SysML), zusätzlich zu Array-basierten DTPLs anwendbar ist.
-
Die Softwareentwicklungsumgebung 224 kann einen Sprachprozessor umfassen, der dazu in der Lage ist, Programmcode in der DTPL zu verarbeiten. Der Sprachprozessor kann ein Compiler, ein Interpreter, eine virtuelle Maschine oder ein anderer Typ einer Ausführungs-Engine oder eine Kombination von einigen oder allen der oben genannten sein.
-
In einigen Implementierungen umfasst die Berechnungseinrichtung 200 keine Softwareentwicklungsumgebung, wie die Umgebung 224. Zum Beispiel kann in einer Ausführungsform mit einer verteilten Berechnungsarchitektur, wie z.B. die Architektur 300, die in 3 gezeigt ist, die Berechnungseinrichtung 200 dazu konfiguriert sein, die Funktionalität eines Code-Generators auszuführen. Die Einrichtung 200 kann durch die NIC 214 über ein Netzwerk 302 ein dynamisch typisiertes Zellarray erhalten, das Programmcode 104 enthält, der relativ zu der Einrichtung 200 entfernt erzeugt ist. Die Einrichtung 200 kann anschließend statisch typisierten Programmcode 102 von dem Programmcode 104 erzeugen, basierend auf Klassifikationen der Zellarrays in Klassen, umfassend homogene oder heterogene Klassen, ohne weitere Entwicklung des Codes. Programmcode 104 kann in solch einer Architektur einer an das Netzwerk angeschlossenen Berechnungseinrichtung 304 erzeugt werden, die eine Array-basierte DTPE 306 hostet. Die Berechnungseinrichtung 304 kann virtuelle Komponenten umfassen und das Netzwerk 302 kann das Internet, ein lokales Netzwerk (LAN), ein Weitverkehrsnetz (VAN), ein drahtloses Netzwerk, ein Intranet, ein Extranet oder ein anderer Typ von Netzwerk sein. In einigen Implementierungen kann die Klient-Berechnungseinrichtung 304 eine Server-Berechnungseinrichtung 200 auffordern, einen Programmcode 104 zu übersetzen, der auf der Klient-Berechnungseinrichtung 304 erzeugt wurde. Die Server-Berechnungseinrichtung 200 kann die Klient-Berechnungseinrichtung 200 mit Software-Produkten oder Komponenten zur Ausführung der Übersetzung oder einen übersetzten Programmcode 102 unter bestimmten Voraussetzungen, wie z.B. einer Lizenzvereinbarung, versorgen.
-
III. Beispiel-Code Erzeugungsverfahren und Einrichtungsimplementierungen
-
Mit Bezug auf das funktionale Blockdiagramm der 1 und dem Flussdiagramm der 4 beschreiben beispielhafte Ausführungsformen eines Code-Generators 108 und eines Verfahrens 400 das Erzeugen von statisch typisiertem Programmcode 102, basierend auf klassifizierten dynamisch typisierten Zellarrays, die im Eingabeprogrammcode 104 enthalten sind oder von diesem generiert sind, umfassend ein oder mehrere dynamisch typisierte Array(s) 106.
-
In Schritt 420 empfängt der Code-Generator 108 Programmcode 104 in einer Quell-DTPL. Eingabeprogrammcode 104 kann automatisch durch eine Berechnungseinrichtung oder manuell durch einen Benutzer oder eine Kombination daraus in einer DTPE erzeugt werden. Der Eingabeprogrammcode 104 umfasst oder, wenn er ausgeführt wird, erzeugt mindestens ein dynamisch typisiertes Array 106 und möglicherweise eine Vielzahl von funktionalen Elementen, die jeweils zu einer bestimmten Funktion oder Operation oder einer Vielzahl von Funktionen oder Operationen korrespondieren. Beispiele von funktionalen Elementen können grafische Blöcke, Anweisungen, Befehle, Module, Skripte, Komponenten, mathematische, logische, statistische oder Eingabe/Ausgabe(E/A)-Operationen, Filter, oder Programmierkonstrukte oder Operationen, wie z.B. if then else, etc. umfassen. Die funktionalen Elemente und ihre Reihenfolge der Ausführung, wenn es eine solche gibt, kann textuell, grafisch oder eine Kombination von textuell und grafisch in Abhängigkeit von der DTPE, die verwendet wird, spezifiziert sein.
-
Der Code-Generator 108 kann auch eine oder mehrere Eingaben 126, wie z.B. Klassenbezeichnungen 128 und/oder Programmpräferenzen 130 empfangen (Schritt 404), wie z.B. gewünschte Leistungskriterien für den Programmcode 102, der erzeugt wird. Eingaben 126 können zum Beispiel von einem Benutzer durch eine Tastatur 216, eine Maus 218 und eine Anzeige 220 der Benutzerschnittstelle 206 empfangen werden. Wenn keine Eingaben 126 empfangen werden kann der Code-Generator 108 Standardklassenbezeichnungen und/oder Kriterien verwenden. Die Klassenbezeichnungen 128 können einen oder mehrere Befehle zum Überstimmen von Klassifikationen umfassen, die durch die Typ-Inferenz-Engine 114 des Code-Generators 108 automatisch zur Anwendung von dynamisch typisierten Array(s) 106 zugewiesen werden, die mit dem Eingabeprogrammcode 104 assoziiert sind. Die Programm-Präferenzen 130 können Spezifikationen hinsichtlich eines zu erreichenden Code-Qualitätsziels oder einer zu verwendenden Ziel-STPL umfassen. Die Programm-Präferenzen 130 können zum Beispiel das Minimieren der Speicheranforderung des Programmcodes 102 (z.B. Minimieren des Speichers, der von temporären Werten konsumiert wird, etc.), Minimierung der Anzahl von Aufrufen oder Vervielfältigungen von einem oder mehreren funktionalen Elementen, Maximierung der Ausführungsgeschwindigkeit des erzeugten Programmcodes 102, Minimierung der Energieanforderungen des generierten Programmcodes 102 etc. umfassen. Die spezifizierten Kriterien können auch spezifische Klassifikationsregeln bestimmen, die zur Anwendung auf die dynamisch typisierten Array(s) 106 ausgewählt werden. Die spezifizierten Kriterien können auch die Code-Sprache umfassen, in der der Code erzeugt wird. Programmpräferenzen 130 können auch eine oder mehrere Bedingungen umfassen, die von dem erzeugten Code 102 erfüllt werden müssen, z.B. Bedingungen, die möglicherweise durch die bestimmte Zielvorrichtung der Implementierung auferlegt werden, z.B. ein Field Programmable Gate Array (FPGA). Der Programmcode 102 kann relativ zu Benutzerspezifikationen optimiert werden oder kann dieselbe Qualität haben, wie handgeschriebener Code, basierend auf Benutzerspezifikationen.
-
In Schritt 406 erstellt ein IR-Builder 110 eine DTIR 111, die die Semantik für Zellarrays 106 festhält. In Schritt 408 empfängt die Typ-Inferenz-Engine 114 des Code-Generators 108 den Eingabeprogrammcode 104 und kann automatisch die dynamisch typisierten Array(s) 106 des Eingabeprogrammcodes 104 als zu einer Klasse zugehörig klassifizieren, umfassend eine homogene Klasse oder eine heterogene Klasse, basierend auf Zellarrayinhalten, Verwendungsmustern und/oder Benutzereingaben, wie vorstehend beschrieben. Die Klassifikation beeinflusst, zum Beispiel bestimmt, wie ein dynamisch typisiertes Array(s) 106 in dem erzeugten Programmcode 102 übersetzt wird.
-
Zum Zweck dieser Offenbarung ist in einigen Implementierungen eine Entität eine Variable, die Daten enthalten kann, zum Beispiel, jedoch nicht darauf beschränkt, einen numerischen Wert, ein Array oder ein Zellarray von Werten, eine Zeichenkette oder ein Objekt etc. Wenn eine Variable mehrere Elemente enthält, wie z.B. ein Array oder ein Zellarray, eine Struktur oder ein Objekt, können die Elemente selbst als Variablen bezeichnet werden.
-
Die Variablen können während der Programmausführung Werte enthalten. In einigen Implementierungen werden "Typen" eingeführt, um gewöhnlich akzeptierte Klassifikationen solcher Werte zu repräsentieren. Beispiele von Typen umfassen primitive Typen, wie Integer und Fließkommazahlen, homogene oder heterogene Arrays von anderen Typen, strukturelle oder Objekttypen mit Elementen, die andere Typen enthalten, etc.
-
In einigen Implementierungen dieser Offenbarung sind die Arrays, z.B. Zellarrays, Variablen, die Sammlungen von Elementen eines ähnlichen oder unterschiedlichen Typs enthalten. Diese Arrays, z.B. Zellarrays, können in Klassen klassifiziert werden, die zur Repräsentation in einer statisch typisierten IR geeignet sind. Einige Beispiele von Arrays werden weiter unten beschrieben.
-
5 illustriert Beispiele eines heterogenen Arrays 502 und eines homogenen Arrays 504. Die Variablen 506 des homogenen Arrays 504 teilen sich eine Vielzahl von Charakteristiken. Zum Beispiel können alle Variablen 506 des homogenen Zellarrays 504 dieselben Datentypen umfassen (z.B. Zahlen, etc.). Bei dem heterogenen Array 502 kann mindestens ein Element einen anderen Datentypen umfassen, als mindestens eine andere Variable. In diesem Beispiel haben in dem heterogenen Array 502 Variablen 508 der Spalte B denselben Datentyp (d.h. textuellen Datentyp), wohingegen Spalten A und C Variablen 510 eines numerischen Datentyps haben.
-
Homogene Zellarrays 504 können eine variable Größe besitzen und können unter Verwendung eines Zugriffsbefehls (z.B. eine Klammer, einen Punkt oder einen Klammerbefehl, etc.) indiziert werden sowie unter Verwendung eines Indexes, dessen Wert während der Laufzeit bestimmt werden kann. In einigen Implementierungen umfasst das Indizieren das Extrahieren von Informationen aus Datencontainern, wie homogene Arrays, heterogene Arrays, etc. Auf eine oder mehrere Variable(n) des Zellarrays kann durch Indices zugegriffen werden, die in einem Index-Ausdruck enthalten sind. Wenn der Wert des Index-Ausdrucks zum Zeitpunkt des Kompilierens bekannt ist, wird das Indizieren manchmal als Konstantindizieren benannt. Zum Beispiel hat, wenn c ein Zellarray ist, c{1} einen konstanten Index vom Wert 1. Wenn n eine Eingabe für das Programm ist, dann hat c{n} keinen konstanten Index, da der Wert von n nicht zum Zeitpunkt des Kompilierens bekannt ist. Stattdessen hängt der Wert von n auf der Programmeingabe zur Laufzeit ab.
-
Heterogene Zellarrays 502 können Variablen umfassen (z.B. Datenelemente), die unterschiedliche Datentypen und/oder -größen, etc. haben. Die Datentypen, die mit heterogenen Arrays 652 assoziiert sind, können deshalb für jedes Element 508 individuell spezifiziert werden. Eine heterogene Klassifikation eines dynamisch typisierten Arrays 106 ist nicht notwendigerweise weniger erstrebenswert (es hängt von dem Anwendungsfall ab), kann jedoch das Anwenden von zusätzlichen Übersetzungsregeln durch den Code-Generator 108 erfordern, um das dynamisch typisierte Array 106 in eine STIR zu übersetzen. Zum Beispiel kann, um in ein heterogenes Array 502 zu indizieren, der Code-Generator 108 einen konstanten Index oder FOR-Schleifen mit konstanten Schranken verwenden oder eine Spezialisierungsfunktion mit konstanten Eingaben erstellen. Der Code-Generator 108 kann homogene Arrays und/oder heterogene Arrays von beliebigen Typen (z.B. Arrays von Arrays, etc.) unterstützen.
-
Wieder mit Bezug zu den 1 und 4, fragt die Typ-Inferenz-Engine 114 des Code-Generators 108 die funktionalen Elemente des Eingabeprogrammcodes 104 und dynamisch typisierte Array(s) 106 ab, um diese, basierend auf Inhalt und/oder Verwendungsmustern (z.B. Zellarrayzugriff, etc.) zu analysieren. Eine Abfragefunktion kann dazu konfiguriert sein, Parameter der funktionalen Elemente des Eingabeprogrammcodes 100 komplett auf einmal, sequenziell oder iterativ oder, wie notwendig, abhängig von Kriterien, die in Eingabeprogrammpräferenzen 130 spezifiziert sind, zu erlangen. Die Typ-Inferenz-Engine 114 kann mit einem Parameterspeicher 132 gekoppelt sein und/oder auf diesen Zugriff haben. Die Abfragefunktion kann auch zusätzliche Informationen erlangen, wie die bevorzugte Traversierungsreihenfolge des funktionalen Elements oder die Benutzungs- oder Zugriffsmuster eines Datensatzes oder Zellarrays, die bevorzugte Datenorganisation des funktionalen Elements, etc. Die Ergebnisse dieser Analysen werden gespeichert und beim Klassifizieren der Array(s) 106 (Schritt 408) verwendet.
-
Die Typ-Inferenz-Engine 114 kann den Klassifikationsprozess auf jeder Variablen, auf einem Strukturfeld, auf einer Klasseneigenschaft, auf einer Zelle in einem anderen Zellarray oder auf einem anderen Objekt oder Entität in dem Programm 102 ausführen, welches ein Zellarray enthält. Diese Variablen und anderen Entitäten können zusammen als "Zellarrayvariablen" bezeichnet werden. Eine Zellarrayvariable kann irgendeinen Datentyp haben, der durch die DTPE unterstützt wird, die die Matrix-basierte DTPL verwendet. Beispiele von Variablen können umfassen: ein logisches Array, ein Zeichenarray, ein numerisches Array (z.B. einen Vektor, eine Matrix oder ein höherdimensionales numerisches Array), ein Zellarray, ein kategorisches Array (weiter unten besprochen), ein Zeitreihenobjekt, ein Array von Strukturen, ein Array von Java-Klassen, ein Array von Funktions-Handlen oder ein Array irgendeines neuen Datentyps, der unter Verwendung einer objektorientierten Klassendefinition erstellt wurde (z.B. jeder neue Datentyp, der unter Verwendung des MatLab-Objektsystems erstellt wurde, z.B. MatLab oops, udd und mcos-Objektsystem). Ein Element einer Variablen kann ein einzelnes Datum in einem Datensatz sein und als solches irgendeinen Datentyp haben, der mit dem Array kompatibel ist, welches die Variable definiert. Zum Beispiel kann für eine numerische Vektorvariable das Element der Variablen eine skalare Zahl sein. Für eine Zellarrayvariable kann das Element der Variablen irgendein Datentyp sein, der mit dem Zellarray kompatibel ist. Für andere Variablen, die homogene Daten enthalten, kann das Element der Variablen irgendein Datentyp sein, den die Variable erfordert, zum Beispiel ein logischer Wert, ein numerisches Array (z.B. ein Vektor, eine Matrix oder ein höherdimensionales numerisches Array), ein kategorisierender Wert, der aus einer endlichen Menge ausgewählt ist (z.B. Rot, Grün oder Blau), oder eine beliebige Textzeichenkette.
-
Der Klassifikationsprozess kann das Anwenden einer oder mehrerer Regeln aus einer Klassifikationsregelmenge 116 auf das/die Zellarray(s) 106 umfassen. Die Klassifikation kann auf der Analyse von Verwendungsmustern für jede Zellarrayvariable basieren. Zum Beispiel kann die Klassifikation darauf basieren, ob die Zellarrayvariablen denselben Datentyp, kompatible Datentypen oder inkompatible Datentypen haben und, ob der Zugriff auf Variablen des Zellarrays konstante oder nicht-konstante Indices verwendet.
-
Ein beispielhaftes Verwendungsmuster eines Zellarrays umfasst ein Programmkonstrukt oder Ausdruck von dem dynamisch typisiertem Eingabeprogrammcode 104, der alle Werte eines dynamisch typisierten Zellarrays 106 liest oder die Werte einer oder einiger Variablen des Zellarrays 106 liest. Zum Beispiel, wenn c ein Zellarray ist, dann sind die Ausdrücke "y = c", "y = c{1}" und "c{i} = 42" Verwendungsmuster von c, jedoch ist "c = a" keines. In Abhängigkeit von der Klassifikation, die dem Zellarray 106 zugewiesen ist, kann das Zellarray dann in eine homogene Datenstruktur (z.B. ein C-Array) oder eine heterogene Datenstruktur (z.B. eine C-Struktur) übersetzt werden.
-
In einer beispielhaften Implementierung kann ein Zellarray unter Verwendung der folgenden einen oder mehreren Regeln einer beispielhaften Klassifikationsregelmenge 116 klassifiziert werden, welches in keinem Fall einschränkend in Bezug auf die Art, auf welche der Klassifikationsschritt 408 durchgeführt werden kann, gemeint ist.
-
Regel 1. Ein Zellarray kann als homogen klassifiziert werden, WENN alle Zellarrayvariablen von demselben Typ sind. Beispiele eines homogenen Arrays umfassen ein Zellarray von Zahlen oder ein Zellarray von Zeichenketten, etc.
-
Regel 2. Ein Zellarray kann als weich-homogenisierbar klassifiziert werden, WENN die assoziierten Zellarrayvariablen einen unterschiedlichen aber ähnlichen Typ haben, so dass ein Zugriff auf eine beliebige Variable in statisch typisiertem Programmcode modelliert werden kann, ohne die Unterschiede zwischen den variablen Typen umzusetzen. Beispiele von weich-homogenisierbaren Arrays umfassen: (a) ein Array von Objekten, die vom selben Basistypen erben, bei dem der Variablenzugriff durch virtuelle Methodenaufrufe modelliert wird; oder (b) ein Array von Matrizen unterschiedlicher Größe, bei denen der Basistyp von allen Matrizen derselbe ist.
-
Regel 3. Ein Zellarray hat eine Klasse mit regelmäßiger Struktur (z.B. eine Tabellenstruktur, etc.), wenn (a) es ein regelmäßiges, sich wiederholendes Muster der Typen von den Variablen in dem Zellarray gibt. Zum Beispiel enthält jede Zeile oder Spalte eines Zellarrays Daten vom gleichen oder von kompatiblen Typen; und (b) das Indizieren entlang der heterogenen Dimensionen des Arrays verwendet konstante Indices, z.B. nur konstante Indices. Zum Beispiel handelt es sich um Konstant-Indizieren, wenn der Wert des Index-Ausdrucks zum Zeitpunkt des Kompilierens bekannt ist. Wenn c ein Zellarray ist, dann hat c{1} einen konstanten Index vom Wert 1. Wenn n in einer Eingabe zu dem Programm, dann hat c{n} keinen konstanten Index, da der Wert von n zum Zeitpunkt des Kompilieren nicht bekannt ist. Stattdessen hängt der Wert von der Programmeingabe zur Laufzeit ab. Ein Beispiel eines Zellarrays mit regelmäßiger Struktur, welche die MatLab-Sprachensyntax verwendet, ist wie folgt:
x = {'John'', 32; 'Steve'', 44; 'Jina'', 11}.
-
Das obige Zellarray x hat eine Tabellenstruktur, in der jede Spalte einen eindeutigen Datentyp hat (Zeichenkette oder numerisch in diesem Fall), wohingegen die Einträge in jeder Zeile unterschiedliche Datentypen enthalten. Regel 4. Ein Zellarray ist heterogen, wenn seine Elemente inkompatible Typen haben. Zum Beispiel umfasst ein heterogenes Zellarray einen Mix von 2 oder mehreren Nummer(n), Zeichen oder Objekten. In einigen Implementierungen verwendet das Indizieren entlang aller Dimensionen des Zellarrays konstante Indices, zum Beispiel nur konstante Indices, damit dieser Klassifikator anwendbar ist.
-
In einigen Implementierungen kann ein Zellarray in mehr als einer Klasse gemäß der oben beschriebenen Kriterien klassifiziert werden, zum Beispiel kann ein Zellarray entweder als heterogen oder weich-homogenisierbar klassifiziert werden. Wenn die Klassifikation uneindeutig oder, basierend auf den Kriterien, nicht bestimmbar ist, kann die Typ-Inferenz-Engine 114 Heuristiken zur Auswahl der Klassifikation verwenden. In einigen Implementierungen kann die Eingabe Klassenbezeichnung 128 eine explizite Auswahl eines Klassifikators unter Verwendung von Compiler-Anweisungen, Anweisungen oder Kommentaren in der Eingabe oder über Kommandozeilenparameter oder grafische Benutzerschnittstellenelemente umfassen. Zum Beispiel kann ein coder.cstructname-Befehl für ein Zellarray aufgerufen werden, der das Zellarray als heterogen klassifiziert, auch wenn die Elemente des Zellarrays kompatible Typen haben, also effektiv jedwede automatische Klassifikationszuweisung überstimmen. Auf ähnliche Weise könnte ein coder.varsize-Befehl verwendet werden, um den Code-Generator 108 dazu zu veranlassen, ein Zellarray als homogen an Stelle von heterogen zu klassifizieren. Die Typ-Inferenz-Engine 114 kann dann den Rest der Klassifikation automatisch ableiten, jedoch nicht die Auswahl, die durch die Klassenzuweisung 128 gemacht wurde, beeinflussen.
-
Zum Beispiel, berücksichtigend das folgende Zellarray:
a = {'Rot', 'Blau', 'Grün'}.
-
Wenn coder.varsize nicht mit dem Zellarray a verwendet, wird, wird a als heterogen klassifiziert, da die drei Variablen des Zellarrays denselben Basisdatentyp haben, jedoch eine unterschiedliche Größe aufweisen. Wenn coder.varsize mit dem Zellarray a verwendet werden würde, würde a als homogen klassifiziert werden. Zum Beispiel, wenn coder.varsize ('a') verwendet wird, kann der Code-Generator 108 bestimmen, dass jede Variable des Arrays eine Klasse "char" und eine Größe 1x:5 aufweist, also eine variable Größe mit bis zu 5 Elementen. In einigen Implementierungen kann der Befehl coder.varsize mit einem Zellarray verwendet werden, wenn der Code-Generator 108 eine gemeinsame Klasse und Größe für alle Elemente bestimmen kann.
-
In einigen Implementierungen erlegt die Klassifikationsregelmenge 116 Anforderung auf Zellarrayzugriffe auf. Zum Beispiel fallen die Indices zum Zugriff auf Variablen in dem Zellarray in ein bestimmtes Muster oder haben konstante Werte. Es ist möglich, dass solche Indices zu uneindeutigen Klassifikationsfällen und Übersetzungsfehlern führen. In einigen Ausführungsformen wird der Klassifikationsschritt der durch die Typ-Inferenz-Engine 114 ausgeführt wird, durch eine Menge von Hilfsprogrammtransformationen 124 unterstützt. In bestimmten Implementierungen kann die Menge von Hilfstransformationen 124 aggressive Funktionsspezialisierung für jede Aufrufstelle, Konstantenweitergabe unter Verwendung von ganzen oder partiellen Konstanten oder automatisches Schleifenabrollen umfassen. Die Hilfstransformationen 124 können helfen, konstante Werte für Zellarrayindices zu entdecken und somit die Wahrscheinlichkeit drastisch erhöhen, dass der Zellarrayklassifikationsschritt 408 erfolgreich jedes Zellarray klassifiziert.
-
Für jede Zellarrayvariable, jedes Strukturfeld oder jede Objekteigenschaft kann die Typ-Inferenz-Engine 114 die folgende Entscheidungssequenz ausführen, nachdem alle Vorkommen von jedem Zellarray 106 in dem Eingabeprogrammcode 104 analysiert sind, die explizit sind oder durch Ausführung der Eingabe 104 erzeugt sind:
WENN eine explizite überstimmende Klassenzuweisung 128 empfangen wird, zum Beispiel von einem Benutzer bereitgestellt,
der bestimmte Klassifikator wird verwendet.
Die Voraussetzungen für jeden Klassifikator werden überprüft.
SONST, WENN alle Zellarrayvariablen (Elemente) gehören zum selben Typen,
Beispiel: Skalare vom Typ Double erzeugen eines homogenen Zellarrays.
Das Zellarray wird als homogen klassifiziert (basierend auf Klassifizierungsregel 1).
SONST, WENN alle Zellarrayvariablen sind Zeichenketten, die variierende Längen haben,
WENN alle Indices sind konstant.
Das Zellarray wird als heterogen klassifiziert (basierend auf Klassifikationsregel 1).
SONST
Das Array wird als weich-homogen klassifiziert mit dem Basistyp "Array von Buchstaben variabler Größe" (basierend auf Klassifikationsregel 2).
ENDE
SONST, WENN alle Indices der Zellelmente sind konstant
Das Zellarray 106 wird als heterogen klassifiziert (basierend auf Klassifikationsregel 4).
SONST, WENN die Zellarrayelemente sind von unterschiedlichem Typ, aber diese Typen sind kompatibel und können durch einen gemeinsamen Typ repräsentiert werden (ein Beispiel, wie der gemeinsame Typ definiert ist, folgt weiter unten).
Das Zellarray 106 wird als weich homogen mit dem korrespondierenden (generalisierten) Basistyp klassifiziert (basierend auf Klassifikationsregel 3).
Beispiel: ein weich-homogenes Zellarray von Matrizen unterschiedlicher Größe.
SONST, WENN das Zellarray 106 hat eine regelmäßige Struktur und alle Verwendungen sind mit dieser konform (sh. regelmäßige Struktur weiter unten).
Das Zellarray 106 kann als regelmäßige Struktur klassifiziert werden (basierend auf Klassifikationsregel 3).
SONST
Kompilieren wird mit einer Fehlernachricht beendet, die den Benutzer zu dem Indexausdruck führt, der nicht auf Konstanten reduziert werden kann.
ENDE
-
In der vorstehenden Beschreibung kann, wann immer eine Abfrage zur Bestimmung ausgeführt wird, ob eine Indexoperation konstante Indices verwendet, die unten beschriebenen Transformationssequenzen angewendet werden, um die konstanten Indices häufiger zu entdecken.
-
Beispiel: Informationen werden empfangen, dass ein Zellarray 106 heterogen ist, dann wird Konstantenweitergabe verwendet, um sicherzustellen, dass alle Indexausdrücke konstant sind. Zum Beispiel erscheinen in der folgenden Sequenz von Programmanweisungen x = 1; m = x + 1; y = c(n); die Indexausdrücke bei c(n) nicht konstant zu sein. Nichtsdestotrotz kann ein konstanter Wert von 2 an den Indexausdruck weitergegeben werden, resultierend in c(2) in dem konstanten Weitergabealgorithmus ohne das Ändern der Datentypen der Elemente.
-
In einigen Implementierungen werden regelmäßige Strukturen, basierend auf den folgenden Methodiken/Verfahren, überprüft. Die regelmäßige Struktur innerhalb des Zellarrays 106 kann detektiert werden und jede Dimension kann z.B. als homogen, heterogen oder anders klassifiziert werden. Verwendungen des Zellarrays 106 werden analysiert und, ob alle Indices, die in Heterogen-Dimensionen verwendet werden, reduziert werden können, wird überprüft.
-
In einigen Implementierungen kann die Typ-Inferenz-Engine 114 eine Sequenz der Hilfsprogrammtransformation 124 anwenden. Einige Beispiele sind unten beschrieben.
-
Transformationssequenz 1 (Konstantenweitergabe oder Vereinfachung konstanter Teile)
-
In einem speziellen heterogenen Array (zum Beispiel ein multidimensionales Datensatz-Array, umfassend Zeilen und Spalten, wie in 5 gezeigt) können Elemente jeder Spalte denselben Datentyp haben, wobei unterschiedliche Spalten unterschiedliche Datentypen haben können. In einigen Fällen kann ein heterogenes Array eine Zeilen oder eine Spalte von Variablen umfassen, die einen homogenen Datentyp haben. Eine der Hilfsprogrammtransformationen 124 kann das Bestimmen von konstanten Indizierungswerten für alle Variablen des dynamisch typisierten Zellarrays 106 involvieren. Eine Konstantenweitergabeoptimierung kann für einem Index-Ausdruck aufgerufen werden, um einen konstanten Wert zu produzieren. In einigen Implementierungen kann die Stärke dieser Transformation und der Grad der Anwendbarkeit durch das Ausführen zusätzlicher Hilfstransformationen (unten beschrieben) verbessert werden, zum Beispiel Funktionsspezialisierung und Schleifenabrollen. Die Hilfstransformationen können nach dem Ausführen dieser Transformation ihrerseits stärker gemacht werden. In einigen Implementierungen können zwei oder mehrere Hilfstransformationen nacheinander in einer Schleife ausgeführt werden.
-
Transformationssequenz 2 (Funktionsspezialisierung)
-
Eine Funktion in dem Eingabeprogrammcode 104 kann für jede Aufrufstelle spezialisiert werden, zum Beispiel durch Hartcodieren der konstanten Parameter von der Aufrufstelle in den Rumpf der Funktion. Diese konstanten Parameter können dann zur Vereinfachung oder Reduzierung der IR der Funktion verwendet werden, wie Abschneiden der IF-Ausdrücke in der Funktion, basierend auf den hartcodierten konstanten Parametern. Zum Beispiel berücksichtigend die folgende MatLab-Funktion:
function y = foo(c, x)
y = c(x);
end
-
Der Indexausdruck in c(x) ist nicht konstant, da er von der Eingabe x abgeleitet wird. Wenn jedoch, zum Beispiel, zwei Aufrufe der Funktion vorliegen, und in beiden Aufrufen der Aufrufende konstante Werte an foo übergibt:
foo(c1, 1);
...
foo(c2, 2);
-
In solch einer Situation können zwei Kopien (Spezialisierungen) von foo produziert werden, wobei x mit einer Kopie und mit 2 in der anderen ersetzt wird:
function y = a_foo(c)
y = c(1);
end
function y = b_foo(c)
y = c(2);
end
-
Beachte, dass der Zellarrayindex nun in beiden Spezialisierungen konstant ist.
-
Transformationssequenz 3 (Schleifenabrollen)
-
Wenn der Indizierungsausdruck eine FOR-Schleifenindexvariable umfasst, dann kann die Schleife, wenn möglich, abgerollt werden, wobei die Indexvariable mit expliziten Werten für jede Iteration ersetzt wird.
-
Transformationssequenz 1 kann für den Ausdruck aufgerufen werden mit dem Ziel, einen konstanten Wert zu produzieren.
-
Diese Transformationen können wiederholt aufgerufen werden, bis kein konstanter Index mehr gefunden wird.
-
Der Fachmann wird erkennen, dass mehr als die oben beschriebenen Klassen zur Klassifizierung verwendet werden können. Zum Beispiel können reguläre/Tabellenstrukturklassen und weich-homogenisierbare Klassen in einigen Implementierungen verwendet werden, wobei jede mit Klassifikationsregeln, Programmtransformationen und Zwischenrepräsentationen Array nach Ausgabecode-Übersetzungsregeln assoziiert ist.
-
In einigen Implementierungen kann die Typ-Inferenz-Engine 114 Heuristiken zur Bestimmung der Klassifikation eines Zellarrays 106 verwenden, zum Beispiel als homogene, heterogene oder andere. Zum Beispiel kann die Typ-Inferenz-Engine 114 die Eigenschaften, zum Beispiel Klasse, Größe oder Komplexität der Zellarrayvariablen und andere Faktoren, wie das Zellarray in der Eingabe verwendet wird, berücksichtigen. Wie oben beschrieben, kann ein Zellarray 106 eine uneindeutige Klassifikation haben, so dass sie homogen in der einen Situation und heterogen in der anderen Situation ist. Zum Beispiel, berücksichtigend das Zellarray {1 [2 3]}. Dieses Zellarray 106 kann als ein heterogenes 1x2 Zellarray klassifiziert werden, dessen erste Variable ein Double-Skalar ist und dessen zweite Variable ein 1x2 Array von Doubles ist. Jedoch, wenn der Source-Code der Eingabe 104 in dem Zellarray 106 mit einem Index indiziert, dessen Wert während der Laufzeit bestimmt wird, kann das Zellarray als homogenes Zellarray klassifiziert werden. Die Variablen dieses Zellarrays umfassen Arrays von Doubles variabler Größe mit einer oberen Schranke von 2.
-
Zum Beispiel profitiert das untenstehende Beispiel vom Anwenden von heuristischen Regeln, um sicherzustellen, dass x als homogen klassifiziert wird, so dass die nachfolgende Verwendung von "z" nicht zu einem Kompilierfehler führt:
x = {1 2 3};
foo(x, i);
function y = foo(z, i)
y = z{e};
-
In einigen Implementierungen können Typ-Unifikationstechniken zur Abgleichung der Klassifikation von unterschiedlichen Zellarrayvariablen verwendet werden, im Fall, dass die Klassifikations-Engine bei unterschiedlichen Klassifikationen für logisch verwandte (zum Beispiel zuweisungsverbunden) Zellarrayvariablen oder Entitäten angelangt ist.
-
Sobald das/die Zellarray(s) 106 im Eingabeprogrammcode 104 klassifiziert ist/sind, wird in Schritt 408 die IR, zum Beispiel die durch den IR-Builder 110 erzeugte DTIR 111, modifiziert werden (Schritt 410), basierend auf der Klassifikation. Die geänderte IR kann in die STIR 112 umgewandelt werden (Schritt 412), welche optimiert werden kann (Schritt 414). Zum Beispiel kann die Ungleichheit von Datentypen in der STIR 112 zum Beispiel durch Verwenden einer oder mehrerer FOR-Schleifenabroll- und Konstantindexweitergabe- und/oder Vereinfachung-konstanter-Teile-Optimierungen, wie oben beschrieben, eliminiert werden. Im Schritt 416 kann die optimierte IR, zum Beispiel die STIR, in Ausgabeprogrammcode übersetzt werden, zum Beispiel durch Verwendung des ST-Programmgenerators 120, umfassend oder erzeugend ein oder mehrere statisch typisierte Arrays 122, die zu dynamisch typisierten Arrays 106 in dem Eingabeprogrammcode 104 korrespondieren. Jeder dieser Schritte wird nun im Detail erklärt.
-
In einigen Implementierungen kann der IR-Builder 110 zuerst die bestimmten Verhaltensweisen des Eingabeprogrammcodes 104 als DTIR 111 modellieren, zum Beispiel angeleitet durch die empfangenen Programmeingaben 126. Dann kann der IR-Builder automatisch die STIR 112 erstellen, die dieselben Verhaltensweisen wie die DTIR modelliert, jedoch mit der Ziel-STPL konsistent ist. Die STIR 112 kann dann in Programmcode 102 in der Ziel-STPL übersetzt werden. Wie bereits angemerkt, definiert die Quell-DTPL das Verhalten von Eingabeprogrammcode 104 und den Zellarray(s) 106 und kann jede DTPL umfassen, die mathematische Arrays unterstützt. Passende DTPEs, die anwendbare Quellensprachen bereitstellen, umfassen Simulink, Stateflow und MatLab von The MathWorks, Incorporated, Natick, Massachusetts. Der Fachmann wird erkennen, dass diese Beispiele von anwendbaren Umgebungen sind und nicht gedacht sind als eine abschließende Liste von anwendbaren Quellsprachen.
-
In einigen Implementierungen kann die STIR 112 einen Kontrollflussgraphen (CFG) umfassen, der die Semantik der Zellarrays 106 einfängt. Eine Zwischenrepräsentation, die ein Zellarray modelliert, kann im Allgemeinen Metadaten umfassen, die Quelle(n) oder andere Attribute des Inhalts in der Zwischenrepräsentation und/oder Metadaten über das Zellarray, zum Beispiel wie auf das Zellarray zugegriffen wird, und/oder die Datentypen der Zellarrayvariablen, etc., identifizieren.
-
Gewöhnliche Implementierungen zur Ausführung von Programmen in einer DTPL erfordern das Einbetten von Typ-Metadaten in der Beschreibung von Variablen und Werten während der Programmausführung. Ein Beispiel von solchen Metadaten ist der VARIANT-Typ in der COM (Common Objects Model von Microsoft), bei der die komplette Klassifikation der Daten, wie der Wert-Typ, die Größe und Struktur innerhalb oder neben dem Wert eingebettet ist. Ein weiteres Beispiel ist die mxArray-Datenstruktur, wie sie von der MatLab Programmierumgebung eingesetzt wird.
-
In einigen Implementierungen können, im Gegensatz zu gewöhnlichen Implementierungen, Implementierungen, die mit dieser Offenbarung konsistent sind, Metadaten in den übersetzten Programmcode einbetten, zum Beispiel den statisch typisierten Code 102. Zum Beispiel können die Metadaten in der Form von statischem Typisieren von Variablen sein. Die Implementierungen können auch die erforderlichen Metadaten vereinfachen, die bei Werte und Variablen notwendig sind, so dass diese nur Aspekte enthalten, die nicht während der Laufzeit statisch bestimmt werden. Des Weiteren können die Implementierungen frei von Metadaten sein. Wenn ein Zellarray in einem Beispiel als homogenes Zellarray fester Größe von vier Elementen klassifiziert ist, wobei jedes Element eine Fließkommazahl enthält, dann würde die Laufzeitrepräsentation dieses Zellarrays lediglich vier Fließkommazahlen von doppelter Genauigkeit sein, die im Computerspeicher verweilen, ohne Extra-Daten, die den Typ oder die Größe oder Struktur dieser Daten beschreiben. Dies ist so, weil der gesamte Code, der auf die Daten zugreift, auf den Daten direkt arbeitet und der Code spezialisiert worden ist und überprüft worden ist auf diesen Daten korrekt zu arbeiten.
-
In einigen Implementierungen können Variablen in dem Quellprogramm, die basierend auf ihrer Verwendung in Ausdrücken oder Arrays innerhalb des Programms in Beziehung stehen, unterschiedlichen Datentypen zugewiesen werden, wenn ein Quellprogramm übersetzt wird, zum Beispiel von einer Eingabe von einer DTPL zu einer STPL. Die Zuweisung kann auf Klassifikationen dieser Variablen basieren, die unterschiedliche Klassenzuweisungen produzieren können. Im Ergebnis kann die ursprünglich erzeugte STIR 112 eine Vielzahl von Typ-Fehlzuordnungen zwischen oder unter in Beziehung stehenden Variablen enthalten. Um eine gute Code-Qualität zu erreichen, kann der IR-Builder 110, zum Beispiel in einem Optimierungsschritt 412, auf eine Menge von Optimierungswerkzeugen zugreifen, um die falsche Zuordnung von Datentypen zu adressieren. Beispiele der Optimierungswerkzeuge können umfassen: Typ-Unifikation, Cast-Eliminierung, Erniedrigung, das heißt Aufbrechen von komplizierten Operationen in einfachere Operationen, etc. Zum Beispiel kann der IR-Builder 110 Typenumwandlungen durch das Verwenden eines Typ-Unifikationsschemas eliminieren, zum Beispiel durch Setzen von falsch zugeordneten Typen auf gemeinsame Typen, die für alle der zugehörigen Variablen angemessen sind. Resultierende ist eine optimierte STIR 112 erzeugt, die die Anforderungen, zum Beispiel wie durch die Präferenzen 130 definiert, etc., für die Code-Qualität des erzeugten Programmcodes 102 erfüllt. In einigen Implementierungen kann Unifikation eingesetzt werden, um die Typen auf der linken Seite und rechten Seite einer Zuweisung identisch zu machen und der neu verwendete Typ kann irgendein Typ sein, zum Beispiel ein Supertyp, der breit genug ist, um beide der originären Typen der linken und rechten Seiten zu umfassen. Ein Beispiel der Anwendung von Typ-Unifikation ist unten beschrieben.
-
Beachte die Zuweisung y = x, in der x ein 1x5 Zellarray und y eine 1x:? ein Zellarray mit demselben Elementtyp ist, wobei :? die Größe angibt, die sich während der Laufzeit ändern kann. Dort liegt eine falsche Typenzuordnung in der Zuweisung vor. Normalerweise erfordert dies eine Umwandlung. Das Unifizieren der Typen von x und y nach 1x:? eliminiert die Notwendigkeit der Umwandlung. Beachte, dass 1x:? allgemeiner ist als 1x5, so dass der Typ von x sicher von 1x5 nach 1x:? geändert werden kann.
-
Sobald die STIR 112 optimiert ist, kann der ST-Programmgenerator 120 die modifizierte STIR 112 in Ausgabeprogrammcode 102 übersetzen (Schritt 414). Der erzeugte Ausgabeprogrammcode 102 wird vom Code-Generator 108 ausgegeben und kann zur weiteren Verarbeitung bereitgestellt werden oder zur Verwendung in der STPE. Der erzeugte Programmcode 102 kann jeder statisch typisierte Quellcode, Objektcode oder ein Kompilat, ein Hash Tag-Datenstruktur oder eine Bibliothek, die eine ausführbare Datei eines Modells bildet, oder irgendeine andere Form von ausführbaren Instruktionen sein. Übersetzen kann das Repräsentieren der klassifizierten Zellarrays als Arrays oder Strukturen (zum Beispiel solche, wie C, C++, Verilog oder HDL-Arrays und Strukturen) oder Hash-Tabellen, in dem Code der der STPL, umfassen.
-
Eine Menge von Übersetzungsregeln 136 kann durch den ST-Programmgenerator 120 verwendet werden, um jede der Zellarrayklassifikationen, wie oben beschrieben, in eine oder mehrere effizientere Repräsentationen solch eines Zellarrays in STPL-Programmcode 120 zu repräsentieren. Eine beispielhafte Menge von Übersetzungsregeln 136 kann das Folgende umfassen:
Regel 1. Homogene Arrays können als traditionelle C-Arrays oder Arrays von Zeigern repräsentiert werden, wobei dünn besetzte homogene Arrays als dünn-besetzte Arrays, Hash-Tabellen oder Suchbäume repräsentiert werden.
Regel 2. Weich-homogenisierbare Zellarrays können als traditionelle Arrays von generalisierten Basistypen, z.B. einen Supertyp von Typen von allen Zellarrayvariablen oder als ein generalisiertes Array von Basistypen, deren Größe kompatibel ist mit der Größe aller Variablen, repräsentiert werden. Die Repräsentation kann das Trennen von heterogenem Speicher mit konkreten Typen von Variablen und homogenem Speicher mit generischen Typen oder Zeigern zu generischen Typen beinhalten. Ein Supertyp kann jegliche Daten repräsentieren, die durch einen Untertyp repräsentiert werden können. Zum Beispiel kann, wenn ein Zellarray zwei Matrizen der Größe 2x2 und 5x5 enthält, diese zu einem Zellarray generalisiert werden, die zwei Matrizen dynamischer Größe enthält, da eine Matrix dynamischer Größe ein 2x2 oder eine 5x5 sein kann. In einigen Implementierungen wird ein Matrixtyp dynamischer Größe durch ein ":"-Symbol bezeichnet, wie :5x:5, was eine Matrix mit bis zu 5 Elementen in jeder Dimension bedeutet; oder :?x:?, was eine Matrix dynamischer Größe bedeutet, deren Größe nicht bestimmt ist, zum Beispiel jede, die in den Speicher des Computer passt.
Regel 3. Regelmäßig strukturierte Arrays können als Arrays von Strukturen repräsentiert werden und in Variablen zerlegt werden.
Regel 4. Heterogene Zellarrays können als traditionelle C-Strukturen repräsentiert werden.
-
Der Übersetzungsprozess kann angemessene Nachvollziehbarkeitsinformationen produzieren, um eine Rückzuordnung von dem generierten Programmcode 102 oder Daten zurück zu dem Quelleingabeprogrammcode 104 in der Quellprogrammiersprache zu erlauben. Die Zuordnung kann Unterstützung für Debugging auf einer hohen Ebene, Code oder Dateninstrumentierung, Profiling oder Selbstbeobachtung von Programmen, die Zellarrays verwenden, bereitstellen.
-
Die vorstehende Offenbarung stellt Illustration und Beschreibung bereit, ist jedoch nicht dazu gedacht, abschließend zu sein oder die Implementierungen auf die präzise Form zu beschränken, wie offenbart. Änderungen und Variationen sind im Licht der obigen Offenbarung möglich oder können durch das Umsetzen der Implementierungen geeignet werden.
-
III. Beispiel von Klassifikation und Übersetzung
-
Ein paar Beispiele der Klassifikations- und Übersetzungsmethoden werden unten gezeigt.
-
Beispiel 1: Das Zellarray ist als homogen klassifiziert und in ein traditionelles Array übersetzt.
-
MATLAB Quellcode für ein homogenes Array:
-
Generierter C code in der statisch typisierten Ausgabesprache enthält ein Array von Typ double, der für die Variable „x“ verwendet wird: double x[9];
-
Beispiel 2: Das Zellarray ist als heterogen klassifiziert und in eine C Struktur übersetzt. Der Quellcode umfasst das Folgende Array, welches als zu einer heterogenen Klasse klassifiziert ist:
-
Generierter C code in der STPL umfasst einen C Struktur-Typ, der für die Variable „x“ verwendet wird:
-
Beispiel 3: Das Array ist weich-homogenisierbar und ist in ein Array von einem generischen Basistyp übersetzt. Der Eingabecode umfasst das Folgende Array, welches als weich-homogenisierbar klassifiziert ist.
-
Generierter C-Code enthält das Array emxArray_cell_warp_0_1x3 variabler Größe, das wiederum ein Array cell_warp_0 variabler Größe enthält. Cell_wrap_0 ist ein generalisierter Typ, der mit einer 5-Element-Zeichenkette und einer 1-Element-Zeichenkette kompatibel ist, die in der Variablen „x“ enthalten sind.
-
IV. Zusammmenfassung
-
Es wird vom Fachmann verstanden werden, dass jede der funktionalen Einheiten, die in den Figuren gezeigt werden, Register und kombinatorische Logik aufweisen kann, die dazu kofiguriert und angeordnet ist, sequenzielle logische Schaltung zu produzieren. Sie können alternativ Software-Module oder Bibliotheken aufweisen, die Programminstruktionen enthalten, die die hierin beschriebenen Verfahren betreffen, die auf einem computer-lesbaren Medium, wie z.B. ein computer-lesbares Medium 230, gespeichert sein können und durch einen oder mehrere Ausführungselemente, wie die CPU 202, ausführbar sind. Auch sind diese nur zum Zwecke der Klarheit als getrennte Rechenentitäten veranschaulicht, ohne andeuten zu wollen, dass diese so konfiguriert sein müssen. Andere computer-lesbaren Medien können auch verwendet werden, um diese Programminstruktionen zu speichern und auszuführen. Nichtsdestotrotz wird der Fachmann erkennen, dass eine Vielzahl von Kombinationen von Software und Hardware, umfassend Firmware, in einer Vielzahl von Implementierungen verwendet werden können.
-
Obgleich spezielle Kombinationen von Merkmalen in den Ansprüchen und/oder in der Beschreibung offenbart sind, sind diese Kombinationen nicht dazu gedacht, die Offenbarung der möglichen Implementierungen zu beschränken. Tatsächlich können einen Vielzahl der Merkmale auf Arten miteinander kombiniert werden, die nicht in den Ansprüchen wiedergeben sind und/oder in der Beschreibung offenbart sind. Obwohl jeder abhängige Anspruch wie unten notiert nur von einem einzigen Anspruch direkt abhängen kann, umfasst die Offenbarung von möglichen Implementierungen die Kombination von jedem abhängigen Anspruch in Abhängigkeit von jedem anderen Anspruch in dem Satz von Ansprüchen.
-
Kein hierin verwendetes Element, keine Handlung oder Instruktion sollte als entscheidend oder essentiell ausgelegt werden, wenn es nicht explizit als solches beschrieben ist. Wie hierin verwendet, ist der Artikel „ein“ dazu angedacht ein oder mehrere Elemente zu umfassen und kann synonym mit „ein oder mehrere“ verwendet werden. Auch soll, wie hierin gebraucht, der Ausdruck „Menge“ ein oder mehrere Elemente umfassen und kann synonym mit „ein oder mehrere“ verwendet werden. An Stellen, an denen nur ein einziges Element angedacht ist, wird der Ausdruck „ein“ oder ein ähnlicher Ausdruck verwendet. Auch sind die Ausdrücke „hat, haben“ oder ähnliche, wie sie hierin verwendet werden als erweiterbare Ausdrücke gedacht. Ferner soll die Formulierung „basiert auf“ bedeuten: „basiert zumindest teilweise auf“, wenn es nicht explizit anders angegeben ist.
-
Auch wenn in einigen Beispielen Zellarrays als Eingabe bereitgestellt werden, so kann die Eingabe auch frei von expliziten Zellarrays sein. Stattdessen können Zellarrays generiert werde, wenn die Eingabe ausgeführt wird. Die Eingabe kann analysiert werden und das oben beschriebene System, die oben beschriebenen Verfahren und die Regeln können angewendet werden, um diese Arrays durch das Ausführen der Eingabe zu erzeugen.
-
Beispiele
-
Die folgenden Beispiele (9 Ausführungsformen) implementieren einen oder mehrere Aspekte der Verfahren und/oder Systeme der vorliegenden Offenbarung. Diese Beispiele sind nicht-einschränkende Beispiele. Merkmale von unterschiedlichen Beispielen können in anderen Implementierungen kombiniert werden. Merkmale von jeder Ausführungsform können in anderen Implementierungen verändert oder entfernt werden.
-
In einer Ausführungsform (Ausführungsform 1) kann das Verfahren zur Erzeugung, z.B. durch einen oder mehrere Prozessoren, von zweitem Programmcode aus erstem Programmcode (nur) die folgenden Schritte umfassen:
- – Analysieren des ersten Programmcodes;
- – Erzeugen von zumindest einer Zwischenrepräsentation, z.B. basierend auf dem ersten Programmcode;
- – Erzeugen des zweiten Programmcodes basierend auf der Zwischenrepräsentation.
Vorzugsweise umfasst der erste Programmcode zumindest ein dynamisch typisiertes Array.
-
In einer Ausführungsform (Ausführungsform 2), kann das Verfahren umfassen:
- – Bestimmen von zumindest einem dynamischen typisierten Array mit zumindest einer Vielzahl von ursprünglichen Elementen, wobei jedes ursprüngliche Element eine ursprüngliche Länge hat, wobei zumindest eines der ursprünglichen Elemente eine ursprüngliche Länge hat, die von einer Länge von zumindest einem anderen ursprünglichen Element verschieden ist, wobei die Elemente vorzugsweise vom selben (Daten-)Typ sind;
- – Bestimmen der maximalen Länge des ursprünglichen Elements;
- – Erzeugen eines statischen Arrays zum Speichern von Daten des dynamisch typisierten Arrays in der Zwischenrepräsentation, wobei das statische Array Zwischenelemente mit konstanter Länge hat, vorzugsweise vom gleichen (Daten-)Typ, wobei die konstante Länge größer oder gleich der maximalen Länge ist.
-
In einer Ausführungsform (Ausführungsform 3) sind die Zwischenelemente und/oder die ursprünglichen Elemente der Ausführungsform 2 Arrays, z.B. von Zeichen.
-
In einer Ausführungsform (Ausführungsform 4) kann das Verfahren einer der Ausführungsformen 1 bis 3 umfassen:
- – Bestimmen mindestens einer Variable in dem ersten Programmcode, wobei die Variable dazu verwendet wird, dynamisch ursprüngliche Elemente in zumindest einem Array zu indizieren, z.B. in mindestens einem dynamisch typisierten Array des ersten Programmcodes,
- – Bestimmen einer Menge von Konstanten, vorzugsweise numerischen, Werten für die Variable;
- – Erzeugen eines (statischen) Arrays zum Halten von Daten des dynamisch typisierten Arrays in der Zwischenrepräsentation, wobei das statische Array Zwischenelemente umfasst;
- – Erzeugen von Code in der Zwischenrepräsentation zum statischen Indizieren zumindest einiger der Zwischenelemente, wobei die Menge von konstanten Werten als Indices verwendet werden;
-
In einer Ausführungsform (Ausführungsform 5) kann das Verfahren nach Ausführungsform 4 umfassen:
- – Analysieren einer Schleife des ersten Programmcodes, wobei die Anzahl der Ausführungen der Schleife durch zumindest einen konstanten numerischen Schrankenwert definiert wird;
- – Bestimmen der Menge von konstanten Werten basierend zumindest teilweise auf dem konstanten, numerischen Schrankenwert.
-
In einer Ausführungsform (Ausführungsform 6) ist die Schleife der Ausführungsform 6 eine zählergesteuerte Schleife und die Variable ist der Zähler in der zählergesteuerten Schleife.
-
In einer Ausführungsform (Ausführungsform 7) kann eines der Verfahren nach zumindest einer der Ausführungsformen 1 bis 6 umfassen:
- – Identifizieren von einer ursprünglichen Funktion in dem ersten Programmcode, wobei die ursprüngliche Funktion ursprüngliche Elemente in mindestens einem Array des ersten Programmcodes indiziert, z.B. in mindestens einem dynamisch typisierten Array, wobei die ursprüngliche Funktion aus einer zählergesteuerten Schleife heraus aufgerufen wird, wobei der Zähler der zählergesteuerten Schleife als Eingabewert der ursprünglichen Funktion verwendet wird;
- – Erzeugen einer Zwischenfunktion in der Zwischenrepräsentation, wobei die Zwischenfunktion die Funktionalität der ursprünglichen Funktion und mindestens einen Eingabeparameter hat;
- – Ersetzen der zählergesteuerten Schleife in der Zwischenrepräsentation durch eine Sequenz von Ausdrücken, wobei die Sequenz von Ausdrücken eine Vielzahl von Funktionsaufrufen der Zwischenfunktion umfasst, wobei jeder Funktionsaufruf mindestens einen konstanten, numerischen Wert als Eingabe für den Eingabeparameter der Zwischenfunktion hat.
-
In einer Ausführungsform (Ausführungsform 8), umfasst das Verfahren nach zumindest einer der Ausführungsformen 1 bis 7:
- – Identifizieren einer zählergesteuerten Schleife in dem ersten Programmcode, wobei der Zähler der zählergesteuerten Schleife zur Indizierung von ursprünglichen Elementen in mindestens einem Array verwendet wird, z.B. in mindestens einem dynamisch typisierten Array des ersten Programmcodes;
- – Erzeugen eines (statischen) Arrays zum Speichern von Daten des dynamisch typisierten Arrays in der Zwischenrepräsentation, wobei das statische Array Zwischenelemente umfasst;
- – Ersetzen der zählergesteuerten Schleife in der Zwischenrepräsentation durch eine Sequenz von Ausdrücken, wobei mindestens einer der Ausdrücke die Zwischenelemente des statischen Arrays (statisch) indiziert.
-
In einer Ausführungsform (Ausführungsform 9), umfasst das Verfahren nach zumindest einer der Ausführungsformen 1 bis 8:
- – Identifizieren einer ursprünglichen Funktion in dem ersten Programmcode, wobei die ursprüngliche Funktion mindestens einen Eingabeparameter hat und ursprüngliche Elemente in mindestens einem Array des ersten Programmcodes indiziert, z.B. in mindestens einem dynamisch typisierten Array, wobei die ursprüngliche Funktion mehrfach mit unterschiedlichen (statischen) Eingabewerten als Eingabeparameter aufgerufen wird;
- – Erzeugen von einer Vielzahl von Zwischenfunktionen für jeden Funktionsaufruf, der auf die ursprüngliche Funktion in der Zwischenrepräsentation gerichtet ist, wobei die Zwischenfunktionen eine ähnliche Funktionalität haben, wie die ursprünglichen Funktionen, wobei in jeder Zwischenfunktion der Eingabeparameter durch einen statischen Eingabewert der Vielzahl von (statischen) Eingabewerten ersetz wird.
-
Instruktionen zum Implementieren einer der Ausführungsformen 1 bis 9, wenn diese Ausgeführt werden, können auf einem nichtflüchtigen computer-lesbaren Medium gespeichert sein.
-
Im Allgemeinen sollen die Begriffe „ursprünglich“ und „zwischen“, insbesondere im Zusammenhang mit den Elementen und/oder der Länge und/Funktionen, in einer nicht einschränkenden Art und Weise verstanden werden und sie werden nur verwendet, um zwischen Elementen/Längen/Funktionen, die zu dem ersten Code gehören, und der entsprechenden Zwischenrepräsentation zu unterscheiden.
