AIX Vektorprogrammierung

Übersicht über Vektorerweiterungen

Die Vektorerweiterung besteht aus einer zusätzlichen Gruppe von 32 128-Bit-Registern, die eine Vielzahl von Vektoren enthalten können, einschließlich 8-Bit-, 16-Bit-oder 32-Bit-Ganzzahlen oder 32-Bit-IEEE-Gleitkommazahlen mit einfacher Genauigkeit. Es gibt einen Vektorstatus und ein Steuerregister, das ein Sticky-Status-Bit enthält, das die Sättigung anzeigt, sowie ein Steuerbit, um den Java™ -oder Nicht-Java-Modus für Gleitkommaoperationen zu aktivieren.

Der von AIX für jeden neuen Prozess initialisierte Standardmodus ist für den Java-Modus aktiviert, der IEEE-konforme Gleitkommaoperationen bereitstellt. Der alternative Nicht-Java-Modus führt zu einem weniger präzisen Modus für Gleitkommaberechnungen, was bei manchen Implementierungen und für bestimmte Operationen deutlich schneller sein kann. Beispiel: Auf dem PowerPC 970 -Prozessor, der im Java-Modus ausgeführt wird, treten einige Vektorgleitkomma-Anweisungen auf, wenn die Eingabeoperanden oder das Ergebnis denormal sind, was zu einer kostenintensiven Emulation durch das Betriebssystem führt. Aus diesem Grund sollten Sie die explizite Aktivierung des Nicht-Java-Modus in Betracht ziehen, wenn die Rundung akzeptabel ist, oder sorgfältig versuchen, Vektorberechnungen für denormale Werte zu vermeiden.

Die Vektorerweiterung umfasst auch mehr als 160 Instruktionen, die einen Lade-und Speicherzugriff zwischen Vektorregistern und Speicher, in Registermanipulation, Gleitkomma-Arithmetik, ganzzahlige arithmetische und logische Operationen und Vektorvergleichsoperationen bereitstellen. Die arithmetischen Gleitkommaanweisungen verwenden das Einzelpräzisionsformat IEEE 754-1985, melden jedoch keine IEEE-Ausnahmen. Standardergebnisse werden für alle Ausnahmebedingungen erzeugt, wie von IEEE für nicht abgefangene Ausnahmebedingungen angegeben. Es wird nur der IEEE-Standardrundungsmodus Round-to-Nearest bereitgestellt. Es werden keine Gleitkommadivision oder Quadratwurzelinstruktionen bereitgestellt, sondern es wird eine reziproke Schätzinstruktion für die Division und eine reziproke Quadratwurzelschätzinstruktion für die Quadratwurzel bereitgestellt.

Es gibt auch ein 32-Bit-Sonderregister, das von Software verwaltet wird, um eine Bitmaske der verwendeten Vektorregister darzustellen. Dies ermöglicht es dem Betriebssystem, Algorithmen für Vektorsicherung und -zurückspeicherung als Teil der Kontextwechselverwaltung zu optimieren.

Laufzeitbestimmung der Vektorfunktion

Ein Programm kann bestimmen, ob ein System die Vektorerweiterung unterstützt, indem es das Feld vmx_version der Struktur _system_configuration liest. Wenn dieses Feld ungleich null ist, enthalten die Systemprozessoren und das Betriebssystem Unterstützung für die Vektorerweiterung. Ein __power_vmx () -Makro wird in /usr/include/sys/systemcfg.h für die Durchführung dieses Tests bereitgestellt. Dies kann für Software nützlich sein, die die Vektorerweiterung bedingt nutzt, wenn sie vorhanden ist, oder um funktional entsprechende skalare Codepfade zu verwenden, wenn sie nicht vorhanden sind.

AIX ABI-Erweiterung

Die AIX Application Binary Interface (ABI) wurde erweitert, um das Hinzufügen von Vektorregisterstatus und Konventionen zu unterstützen. Eine vollständige Beschreibung der ABI-Erweiterungen finden Sie im Handbuch Assembler Language Reference .

AIX unterstützt die Spezifikation der AltiVec -Programmierschnittstelle. Nachfolgend finden Sie eine Tabelle der C-und C + + -Vektordatentypen. Alle Vektordatentypen sind 16 Byte groß und müssen an einer 16-Byte-Grenze ausgerichtet werden. Aggregate, die Vektortypen enthalten, müssen den normalen Konventionen zum Ausrichten des Aggregats an der Anforderung des größten Members entsprechen. Wenn ein Aggregat, das einen Vektortyp enthält, gepackt wird, gibt es keine Garantie für die 16-Byte-Ausrichtung des Vektortyps. Ein AIX -Compiler, der die Programmierschnittstellenspezifikation AltiVec unterstützt, ist erforderlich.

In der folgenden Tabelle sind die Verwendungskonventionen für Vektorregister aufgeführt.

Die Spezifikation der AltiVec -Programmierschnittstelle definiert das VRSAVE-Register, das als Bitmaske von verwendeten Vektorregistern verwendet werden soll. AIX erfordert, dass eine Anwendung das VRSAVE-Register nie ändert.

Die ersten 12 Vektorparameter in einer Funktion werden in VR2 bis VR13platziert. Nicht benötigte Vektorparameterregister enthalten nicht definierte Werte beim Eintritt in die Funktion. Argumentlistenvektorparameter mit nicht variabler Länge werden in Allgemeinregistern (GPRs) nicht gespiegelt. Alle zusätzlichen Vektorparameter, ab 13th und darüber hinaus, werden durch den Speicher auf dem Programm-Stack, 16 Byte ausgerichtet, an ihrer entsprechenden zugeordneten Position innerhalb des Parameterbereichs entsprechend ihrer Position in der Parameterliste übergeben.

Bei Argumentlisten variabler Länge ist va_list weiterhin ein Zeiger auf die Speicherposition des nächsten Parameters. Wenn va_arg () auf einen Vektortyp zugreift, muss va_list zuerst an einer 16-Byte-Grenze ausgerichtet werden. Der Empfänger oder Konsument einer Argumentliste variabler Länge ist für die Ausführung dieser Ausrichtung verantwortlich, bevor der Vektortypparameter abgerufen wird.

Eine nicht gepackte Struktur oder Union, die von einem Wert übergeben wird, der ein Vektorelement an einer beliebigen Stelle enthält, wird an einer 16-Byte-Grenze im Stack ausgerichtet.

Eine Funktion, die eine Argumentliste variabler Länge verwendet, hat alle Parameter, die im Argumentbereich zugeordnet sind, sortiert und entsprechend ihren Typen ausgerichtet. Die ersten acht Wörter (32 Bit) oder Doppelwörter (64 Bit) einer Argumentliste variabler Länge werden in GPRs r3 - r10gespiegelt. Dies schließt Vektorparameter ein.

Funktionen, deren Rückgabewert als Vektordatentyp deklariert ist, platzieren den Rückgabewert in VR2. Jede Funktion, die einen Vektortyp zurückgibt oder Vektorparameter hat, erfordert einen Funktionsprototyp. Dadurch wird vermieden, dass der Compiler die VRs in GPRs für den allgemeinen Fall gespiegelt.

Traditionelle ABI-Kompatibilität und -Interoperabilität

Aufgrund der Art von Schnittstellen (z. B. setjmp (), longjmp (), sigsetjmp (), siglongjmp (), _setjmp (), _longjmp (), getcontext (), setcontext (), makecontext () und swapcontext ()), die den nicht flüchtigen Maschinenstatus speichern und wiederherstellen müssen, besteht ein Risiko, wenn Abhängigkeiten zwischen traditionellen und vektorerweiterten ABI-Modulen berücksichtigt werden. Um die Sache zu komplizieren, befindet sich die setjmp-Familie von Funktionen in libc in einem statischen Member von libc, Dies bedeutet, dass jede vorhandene AIX -Binärdatei über eine statisch gebundene Kopie der setjmp-Familie verfügt und andere, die mit der Version von AIX , mit der sie verknüpft wurde, vorhanden waren. Außerdem verfügen vorhandene AIX -Binärdateien über jmpbufs-und ucontext-Datenstrukturdefinitionen, die nicht ausreichen, um zusätzliche nicht flüchtige Vektorregisterstatus zu speichern.

Alle Fälle, in denen traditionelle Module und neue Module Aufrufe oder Callbacks, bei denen ein traditionelles Modul einen longjmp () oder setcontext () ausführen könnte, unter Umgehung der normalen Verbindungskonvention eines Vektorerweiterungsmoduls, haben das Risiko, dass der nicht flüchtige Vektorregisterstatus beeinträchtigt wird.

Aus diesem Grund definiert die AIX -ABI nicht flüchtige Vektorregister. Der Standardkompilierungsmodus bei der Verwendung von Vektoren (AltiVec) in AIX -Compilern besteht darin, keines der nicht flüchtigen Vektorregister zu verwenden. Dies führt zu einer Standardkompilierungsumgebung, die die Nutzung von Vektoren (AltiVec) sicher ermöglicht und gleichzeitig kein Risiko hinsichtlich der Interoperabilität mit traditionellen Binärdateien birgt.

Für Anwendungen, bei denen Interoperabilität und Modulabhängigkeit vollständig bekannt sind, kann eine zusätzliche Kompilierungsoption aktiviert werden, die die Verwendung nicht flüchtiger Vektorregister ermöglicht. Dieser Modus sollte nur verwendet werden, wenn alle abhängigen traditionellen Module und Verhaltensweisen vollständig bekannt sind und entweder keine Abhängigkeit von Funktionen wie setjmp (), sigsetjmp (), _setjmp () oder getcontext () aufweisen oder wenn sichergestellt ist, dass alle Modulübergänge unter Verwendung der normalen Subroutinenverbindungskonvention ausgeführt werden und dass keine Rückrufe zu einem vorgeschalteten traditionellen Modul verwendet werden.

Die Standardkompilierungsumgebung AltiVec definiert __VEC__gemäß dem AltiVec Technology Programming Interface Manualvordefiniert.

Wenn die Option zur Verwendung nicht flüchtiger Vektorregister aktiviert ist, muss die Kompilierungsumgebung auch __EXTABI__vordefinieren. Sie können nicht vektorfähige Module für die Erweiterung von ABI-fähigen Modulen kompilieren, indem Sie __AIXEXTABIexplizit definieren. Dadurch wird sichergestellt, dass diese Module sicher mit vektorfähigen Modulen interagieren können, die für die Verwendung nicht flüchtiger Vektorregister aktiviert sind.

Erweiterter Kontext

Um den zusätzlichen Maschinenstatus zu unterstützen, der für die Vektorerweiterung erforderlich ist, sowie andere Erweiterungen wie Benutzerschlüssel, hat AIX 5.3 die Unterstützung für erweiterte Kontextstrukturen eingeführt. Die primäre anwendungssichtbare Verwendung von Maschinenkontextinformationen ist ihre Anwesenheit in der Sigkontext-Struktur, die Signalhandlern zur Verfügung gestellt wird, und die resultierende Aktivierung des Maschinenkontextes im Sigcontext bei der Rückgabe vom Signalhandler. Die sigcontext-Struktur ist eigentlich eine Untergruppe der größeren ucontext-Struktur. Die beiden Strukturen sind bis zur Größe identisch (struct sigcontext). Wenn AIX einen Signalkontext erstellt, der an einen Signalhandler übergeben werden soll, wird tatsächlich eine ucontext-Struktur im Stack des Signalhandlers erstellt. Der Maschinenkontextabschnitt eines Signalkontexts muss den gesamten aktiven Maschinenzustand (flüchtig und nicht flüchtig) für den unwillkürlich unterbrochenen Kontext enthalten. Um dies zu erreichen, ohne die Binärkompatibilität mit vorhandenen Signalhandlern zu beeinträchtigen, dient der zuvor in der ucontext-Struktur reservierte Speicherplatz nun als Hinweis darauf, ob erweiterte Kontextinformationen verfügbar sind.

Ein neu definiertes Feld im ucontext, __extctxist die Adresse einer erweiterten Kontextstruktur, struct __extctx, wie in der Datei sys/context.h definiert. Ein neues Feld, __extctx_magic, in der ucontext-Struktur gibt an, ob die erweiterten Kontextinformationen gültig sind, wenn der Wert von __extctx_magic gleich __EXTCTX_MAGICist. Der zusätzliche Vektormaschinenzustand für einen Thread, der die Vektorerweiterung verwendet, wird gespeichert und als Mitglied dieser neuen Kontexterweiterung zur ucontext-Struktur als Teil der Signalbereitstellung und -rückgabe wiederhergestellt.

Die ucontext-Struktur wird auch für APIs (wie getcontext (), setcontext (), swapcontext () und makecontext ()) verwendet. In diesen Fällen ist der Kontext, der gespeichert werden muss, auf eine freiwillige Aktion zurückzuführen, für die die Aufrufverbindungskonvention nur das Speichern des nicht flüchtigen Maschinenstatus erfordert. Da der Standardmodus der Vektoraktivierung unter AIX, wie im Abschnitt ABI beschrieben, darin besteht, keine nicht flüchtigen Vektorregister zu verwenden, gibt es keine Erweiterungen der ucontext-Struktur, die für die meisten Anwendungen erforderlich sind. Wenn eine Anwendung die Verwendung von nicht flüchtigen Vektorregistern explizit aktiviert, nimmt sie eine ucontext-Struktur mit erweiterter Größe auf, die bereits Platz für das Feld __extctx hat, das durch die implizite Definition von _____ durch den Compiler eingeschlossen wird. Der erweiterte ucontext kann auch von einer expliziten Definition von __AIXEXTABIübernommen werden.

In ähnlicher Weise erfordert jmp_buf für die Verwendung mit setjmp () oder longjmp () keine Änderung für vektoraktivierte Standardanwendungen, da keine nicht flüchtigen Vektorregister verwendet werden. Die explizite Aktivierung von nicht flüchtigen Vektorregistern führt aufgrund der impliziten Definition von __EXTABI__ durch den Compiler zu größeren jmp_buf-Zuordnungen. Die erweiterten Sprungpuffer können auch durch explizite Definition von __AIXEXTABI aktiviert werden.

Ein detaillierteres Layout der erweiterten Kontextinformationen finden Sie in der Headerdatei sys/context.h .

Vektorspeicherzuordnung und -ausrichtung

Vektordatentypen führen einen Datentyp ein, der eine 16-Byte-Ausrichtung erfordert. In Übereinstimmung mit der Programmierschnittstellenspezifikation AltiVec wird eine Gruppe von malloc-Subroutinen (vec_malloc, vec_free, vec_realloc, vec_calloc) von AIX bereitgestellt, die 16-Byte-ausgerichtete Zuordnungen ermöglichen.

Eine vektorbasierte Kompilierung, bei der _VEC_ implizit vom Compiler definiert wird, führt dazu, dass alle Aufrufe von traditionellen malloc und calloc an ihre vektorsicheren Entsprechungen vec_malloc bzw. vec_calloc umgeleitet werden. Nicht-Vektorcode kann auch explizit kompiliert werden, um dieselben malloc-und calloc-Umleitungen zu berücksichtigen, indem __AIXVECexplizit definiert wird. Die Ausrichtung der Standardzuordnungen für malloc (), realloc () und calloc () kann auch zur Laufzeit gesteuert werden.

MALLOCALIGN=16;  export MALLOCALIGN

Die Umgebungsvariable MALLOCALIGN kann auf eine beliebige Potenz von 2 größer-gleich der Größe eines Zeigers im entsprechenden Ausführungsmodus (4 Byte für 32-Bit-Modus, 8 Byte für 64-Bit-Modus) gesetzt werden. Wenn MALLOCALIGN auf einen ungültigen Wert gesetzt ist, wird der Wert auf die nächste Potenz von 2 aufgerundet und alle nachfolgenden malloc () -Zuordnungen werden an diesem Wert ausgerichtet.

rc = mallopt(M_MALIGN, 16);

Weitere Informationen finden Sie unter mallopt und MALLOCALIGN.

printf und scanf von Vektordatentypen

In Übereinstimmung mit der Spezifikation der AltiVec -Programmierschnittstelle wird Unterstützung für die AIX -Versionen von scanf, fscanf, sscanf, wsscanf, printf, fprintf, sprintf, snprintf, wsprintf, vprintf, vfprintf, vsprintf und vwsprintf für die neuen Formatzeichenfolgen der Vektorkonvertierung hinzugefügt. Die neuen Größenformatierungsprogramme lauten wie folgt:

• 'vl' oder 'lv' verarbeitet ein Argument und ändert eine vorhandene Ganzzahlkonvertierung. Dies führt zu einer Vektorkonvertierung des Typs 'int', 'vector unsigned int' oder 'vector bool' für Ausgabekonvertierungen oder 'vector signed int *' oder 'vector unsigned int *' für Eingabekonvertierungen. Die Daten werden dann als eine Reihe von vier 4-Byte-Komponenten behandelt, auf die jeweils das nachfolgende Konvertierungsformat angewendet wird.
• 'vh' oder 'hv' verarbeitet ein Argument und ändert eine vorhandene kurze ganzzahlige Konvertierung, die zu einer Vektorkurzform mit Vorzeichen oder einer Vektorkurzform ohne Vorzeichen für Ausgabekonvertierungen oder zu einer Vektorkurzform mit Vorzeichen * oder einer Vektorkurzform ohne Vorzeichen * für Eingabekonvertierungen führt. Die Daten werden als eine Reihe von acht 2-Byte-Komponenten behandelt, auf die jeweils das nachfolgende Konvertierungsformat angewendet wird.
• v verarbeitet ein Argument und ändert eine 1-Byte-Ganzzahl, ein 1-Byte-Zeichen oder eine 4-Byte-Gleitkommakonvertierung. Wenn es sich bei der Konvertierung um eine Gleitkommakonvertierung handelt, ist das Ergebnis ein Vektorgleitkomma für die Ausgabekonvertierung oder ein Vektorgleitkomma * für die Eingabekonvertierung. Die Daten werden als eine Reihe von vier 4-Byte-Gleitkommakomponenten behandelt, auf die jeweils das nachfolgende Konvertierungsformat angewendet wird. Wenn die Konvertierung eine Ganzzahl-oder Zeichenkonvertierung ist, ist das Ergebnis entweder ein Vektor mit Vorzeichen char, ein Vektor ohne Vorzeichen char oder ein Vektor bool char für die Ausgabekonvertierung oder ein Vektor mit Vorzeichen char * oder ein Vektor ohne Vorzeichen char * für Eingabekonvertierungen. Die Daten werden als eine Reihe von 16 1-Byte-Komponenten behandelt, wobei jeweils das nachfolgende Konvertierungsformat angewendet wird.

Jedes Konvertierungsformat, das auf die singuläre Form eines Vektor-Datentyps angewendet werden kann, kann mit einer Vektorform verwendet werden. Die %d-, %x-, %X-, %u-, %i-und %o -Ganzzahlkonvertierungen können mit %lv, %vl, %hv, %vh, und %v Vektorlängenqualifikationsmerkmale. Die %c -Zeichenkonvertierung kann mit dem Qualifikationsmerkmal für die Vektorlänge %v angewendet werden. Die %a-, %A-, %e-, %E-, %f-, %F-, %g-und %G-Gleitkomma-Konvertierungen können mit dem Qualifikationsmerkmal für die Vektorlänge %v angewendet werden.

Bei Eingabekonvertierungen kann ein optionales Trennzeichen ohne Leerzeichen vor dem Trennzeichen angegeben werden. Wenn kein Trennzeichen angegeben wird, ist das Standardtrennzeichen ein Leerzeichen, das Leerzeichen vor dem Trennzeichen enthält, es sei denn, die Konvertierung ist c und die Standardkonvertierung ist null.

Bei Ausgabekonvertierungen kann ein optionales Trennzeichen unmittelbar vor der Vektorgrößenkonvertierung angegeben werden. Wenn kein Trennzeichen angegeben wird, ist das Standardtrennzeichen ein Leerzeichen, es sei denn, die Konvertierung ist c, und das Standardtrennzeichen ist null.

Thread-Anwendungen

Multithread-Anwendungen, die die Vektorerweiterung nutzen, werden ebenfalls unterstützt. Diese Anwendungen werden sowohl im Systembereich (1:1-Threading-Modell) als auch im Prozessbereich (M: N-Threading-Modell) unterstützt. Wenn eine Multithread-Anwendung mit aktivierten, nicht flüchtigen Vektorregistern kompiliert wird, werden die pthreads für diese Anwendung als erweiterte ABI pthreads markiert. Das Ergebnis sind größere Kontextspeicherpufferzuordnungen in der pthread-Bibliothek für diese Threads. Der dbx AIX -Debugger bietet auch vollständige Unterstützung für das Debugging von vektorfähigen Multithread-Programmen auf Maschinenebene.

Compiler

Ein AIX -Compiler, der die Vektorerweiterung unterstützt, muss der AIX ABI Vector Extension entsprechen. Wie zuvor beschrieben, sollte der standardmäßige vektoraktivierte Kompilierungsmodus unter AIX bei inaktivierter Verwendung nicht flüchtiger Vektorregister verwendet werden. Eine explizite Option zum Aktivieren der Verwendung von nicht flüchtigen Vektorregistern kann nach Ihrem Ermessen bereitgestellt und aktiviert werden, nachdem Sie die Probleme und Risiken in Bezug auf die Interoperabilität neuer und alter Module verstanden haben.

Wenn Sie die Verwendung von nicht flüchtigen Vektorregistern aktivieren, muss ein C-oder C + + -Compiler __EXTABI__vordefinieren. Außerdem wird bei Aktivierung für jede Form der Vektorkompilierung erwartet, dass ein C-oder C + + -Compiler __VEC__vordefiniert. Wenn Sie nicht vektorfähige C-oder C + + -Module für die Verknüpfung mit vektoraktivierten Fortran -Modulen kompilieren, empfiehlt es sich, die C-oder C + + -Module explizit mit mindestens __AIXVEC -Definition zu kompilieren (explizite Definition analog zu __VEC__). sowie __AIXEXTABI (explizite Definition analog zu __EXTABI), wenn nicht flüchtige Vektorregister in den Fortran -Modulen aktiviert sind.

Zusätzlich zur AltiVec -Programmierschnittstellenspezifikation, die eine explizite Erweiterung der C-und C + + -Sprachen für die Vektorprogrammierung bereitstellt, ermöglichen einige Compiler wahrscheinlich die Nutzung der Vektorerweiterung in einigen Optimierungseinstellungen, wenn sie auf einen Prozessor abzielen, der die Vektorerweiterung unterstützt.

Weitere Details finden Sie in der Compilerdokumentation.

Assembler

Der AIX -Assembler im Verzeichnis /usr/ccs/bin/as unterstützt jetzt den zusätzlichen Instruktionssatz, der von der Vektorerweiterung definiert und speziell vom PowerPC 970 -Prozessor implementiert wird. Sie können den neuen Assemblierungsmodus -m970 oder den Pseudoop .machine 970 in der Quellendatei verwenden, um die Assemblierung der neuen Vektoranweisungen zu aktivieren. Weitere Informationen finden Sie im Handbuch Assembler Language Reference .

Debugging-Tool

Der Debugger dbx AIX in /usr/ccs/bin/dbx, unterstützt das Debugging auf Maschinenebene für vektoraktivierte Programme. Diese Unterstützung beinhaltet die Fähigkeit, die neuen Vektoranweisungen zu zerlegen und Vektorregister anzuzeigen und festzulegen. Ein neuer $instructionset-Wert von 970 wurde definiert, um die Disassemblierung der PowerPC 970-spezifischen Anweisungen, einschließlich der Vektoranweisungen, zu ermöglichen, wenn dbx nicht auf einem PowerPC 970 -System ausgeführt wird. Beachten Sie, dass bei der Ausführung von dbx auf einem PowerPC 970der Standardwert für $instructionset 970 lautet.

Um Vektorregister anzuzeigen, muss der Unterbefehl unset $novregs verwendet werden, da Vektorregister standardmäßig nicht angezeigt werden. Wenn der Prozessor die Vektorerweiterung nicht unterstützt oder der zu untersuchende Prozess oder Thread die Vektorerweiterung nicht verwendet, wird kein Vektorregisterstatus angezeigt. Andernfalls gibt der Unterbefehl registers alle Vektorregister und ihren Inhalt im unformatierten Hexadezimalformat aus.

Sie können die Vektorregister auch einzeln anzeigen, formatiert nach einem Grundtyp. Wenn Sie beispielsweise $vr0 drucken, wird der Inhalt des Registers VR0 als Array mit 4 ganzen Zahlen angezeigt. print $vr0c zeigt den Inhalt des Registers VR0 als Array von 16 Zeichen an. print $vr0s zeigt den Inhalt von Register VR0 als Array mit 8 Shorts an und $vr0f zeigt den Inhalt von Register VR0 als Array mit 4 Floats an.

Sie können ganze Vektorregister zuweisen, z. B. $vr0 = $vr1, oder einzelne Vektorelemente des Vektorregisters zuweisen, als würden Sie ein Element eines Arrays zuweisen. Beispiel: assign $vr0[3] = 0x11223344 legt nur das 4th ganzzahlige Mitglied von VR0fest. assign $vr0f[0] = 1.123 führt dazu, dass nur das erste Gleitkommaelement von VR0 auf den Wert 1.123festgelegt wird.

Sie können Vektorregister während der Ausführung einer Funktion oder eines Programms verfolgen. Beispielsweise zeigt tracei $vr0 in main den Inhalt von VR0 bei jeder Änderung in main () an. Wenn Sie eines der Formatregister ($vr0f, $vr0c, $vr0s) für tracei angeben, wird jede Anzeige des Inhalts entsprechend formatiert.

Solange Compiler Vektordatentypen als Arrays ihrer grundlegenden Typen darstellen, sollte dbx auch in der Lage sein, einen als Array formatierten Vektordatentyp anzuzeigen.

Weitere Informationen finden Sie in der Dokumentation zum Befehl dbx .

Die Aktivierung für Debugger anderer Anbieter wird auch in Form der neuen ptrace-Operationen PTT_READ_VEC und PTT_WRITE_VEC zum Lesen oder Schreiben des Vektorregisterstatus für einen Thread bereitgestellt. Weitere Informationen finden Sie in der Dokumentation zu ptrace.

Das Dateisystem /proc wurde ebenfalls erweitert, um einen auf /procbasierenden Debugger zu unterstützen. Die Statusdateien und die lwpstatus-Dateien für einen vektorfähigen Prozess bzw. Thread werden um den Vektorregisterstatus erweitert. Eine neue Steuernachricht, PCSVREG, wird beim Schreiben einer Prozess-oder Threadsteuerdatei zum Festlegen des Vektorregisterstatus unterstützt. Weitere Informationen finden Sie im Handbuch /proc File Reference.

Kerndateien

AIX unterstützt auch die Einbeziehung des Vektormaschinenstatus als Teil der Kerndatei für einen vektorfähigen Prozess oder Thread. Nur wenn ein Prozess oder Thread die Vektorerweiterung verwendet, wird der Status der Vektormaschine in das Kernimage für diesen Thread eingeschlossen. Beachten Sie, dass bei Auswahl des Kerndateiformats vorAIX 4.3 der Vektorstatus nicht eingeschlossen wird. Der Vektorstatus wird nur in den aktuellen Kerndateiformaten unterstützt. Mit dem Befehl dbx können Sie den Status der Vektormaschine einer vektorfähigen Kerndatei lesen und anzeigen.