Programación de vectores de AIX

Visión general de la extensión de vector

La extensión de vector consta de un conjunto adicional de 32 registros de 128 bits que pueden contener una variedad de vectores incluyendo enteros de 8 bits, 16 bits o 32 bits firmados o sin firmar, o flotantes de precisión única IEEE de 32 bits. Hay un estado de vector y un registro de control que contiene un bit de estado de permanencia que indica saturación, así como un bit de control para habilitar Java™ o la modalidad no Java para operaciones de coma flotante.

La modalidad predeterminada inicializada por AIX para cada nuevo proceso está habilitada en modalidad Java, que proporciona operaciones de coma flotante compatibles con IEEE. La modalidad alternativa no Java da como resultado una modalidad menos precisa para los cálculos de coma flotante, que puede ser significativamente más rápida en algunas implementaciones y para operaciones específicas. Por ejemplo, en el procesador PowerPC 970 que se ejecuta en modalidad Java, algunas instrucciones de coma flotante de vector encontrarán una excepción si los operandos de entrada o el resultado son denórmicos, lo que da como resultado una emulación costosa por parte del sistema operativo. Por esta razón, se recomienda que considere la posibilidad de habilitar explícitamente la modalidad no Java si el redondeo es aceptable, o que intente cuidadosamente evitar cálculos vectoriales en valores denórmicos.

La extensión de vector también incluye más de 160 instrucciones que proporcionan acceso de carga y almacenamiento entre registros de vector y memoria, en manipulación de registro, aritmética de coma flotante, operaciones aritméticas y lógicas enteras, y operaciones de comparación de vector. Las instrucciones aritméticas de coma flotante utilizan el formato de precisión simple IEEE 754-1985, pero no notifican excepciones IEEE. Los resultados predeterminados se generan para todas las condiciones de excepción especificadas por IEEE para las excepciones no atrapadas. Sólo se proporciona la modalidad de redondeo IEEE por omisión de redondeo de redondeo a más cercano. No se proporcionan instrucciones de división de coma flotante o de raíz cuadrada, sino que se proporciona una instrucción de estimación recíproca para la división, y se proporciona una instrucción de estimación de raíz cuadrada recíproca para la raíz cuadrada.

También existe un registro de propósito especial de 32 bits que es gestionado por software para representar una máscara de bits de registros vectoriales en uso. Esto permite al sistema operativo optimizar los algoritmos de salvar y restaurar vectores como parte de la gestión de conmutadores de contexto.

Determinación en tiempo de ejecución de la prestación de vector

Un programa puede determinar si un sistema soporta la extensión de vector leyendo el campo vmx_version de la estructura _system_configuration. Si este campo no es cero, los procesadores del sistema y el sistema operativo contienen soporte para la extensión de vector. Se proporciona una macro __power_vmx () en /usr/include/sys/systemcfg.h para realizar esta prueba. Esto puede ser útil para el software que explota condicionalmente la extensión de vector cuando está presente, o para utilizar vías de acceso de código escalar funcionalmente equivalentes cuando no está presente.

AIX Extensión ABI

La interfaz binaria de aplicación (ABI) de AIX se ha ampliado para dar soporte a la adición de estado y convenios de registro de vector. Consulte la publicación Assembler Language Reference para obtener una descripción completa de las extensiones ABI.

AIX da soporte a la especificación de la interfaz de programación AltiVec . A continuación se muestra una tabla de los tipos de datos de vector C y C++. Todos los tipos de datos de vector tienen un tamaño de 16 bytes y deben estar alineados en un límite de 16 bytes. Los agregados que contienen tipos de vector deben seguir las convenciones normales de alinear el agregado con el requisito de su miembro más grande. Si se empaqueta un agregado que contiene un tipo de vector, no hay ninguna garantía de alineación de 16 bytes del tipo de vector. Se necesita un compilador AIX que dé soporte a la especificación de interfaz de programación AltiVec .

En la tabla siguiente se describen los convenios de uso del registro de vector.

La especificación de la interfaz de programación AltiVec define el registro VRSAVE que se utilizará como máscara de bits de los registros de vector en uso. AIX requiere que una aplicación nunca modifique el registro VRSAVE.

Los primeros 12 parámetros de vector de una función se colocan en VR2 a través de VR13. Los registros de parámetros vectoriales innecesarios contienen valores no definidos al entrar en la función. Los parámetros de vector de lista de argumentos de longitud no variable no se sombrean en los registros de propósito general (GPR). Cualquier parámetro de vector adicional, desde 13th y más allá, se pasa a través de la memoria en la pila de programa, alineada de 16 bytes, en su ubicación correlacionada adecuada dentro de la región de parámetro correspondiente a su posición en la lista de parámetros.

Para listas de argumentos de longitud variable, va_list continúa siendo un puntero a la ubicación de memoria del siguiente parámetro. Cuando va_arg () accede a un tipo de vector, va_list debe alinearse primero con un límite de 16 bytes. El receptor o consumidor de una lista de argumentos de longitud variable es responsable de realizar esta alineación antes de recuperar el parámetro de tipo de vector.

Una unión o estructura no empaquetada pasada por un valor que tiene un miembro de vector en cualquier lugar dentro del mismo se alineará con un límite de 16 bytes en la pila.

Una función que toma una lista de argumentos de longitud variable tiene todos los parámetros correlacionados en el área de argumentos ordenados y alineados según sus tipos. Las primeras ocho palabras (32 bits) o palabras dobles (64 bits) de una lista de argumentos de longitud variable se sombrean en GPRs r3 - r10. Esto incluye parámetros de vector.

Las funciones que tienen un valor de retorno declarado como tipo de datos de vector colocan el valor de retorno en VR2. Cualquier función que devuelva un tipo de vector o tenga parámetros de vector requiere un prototipo de función. Esto evita que el compilador sombree las VR en los GPR para el caso general.

Compatibilidad e interoperabilidad de ABI heredadas

Debido a la naturaleza de las interfaces (tales como setjmp (), longjmp (), sigsetjmp (), siglongjmp (), _setjmp (), _longjmp (), getcontext (), setcontext (), makecontext () y swapcontext ()) que deben guardar y restaurar el estado de la máquina no volátil, existe un riesgo al considerar las dependencias entre los módulos ABI heredados y ampliados por vectores. Para complicar las cosas, la familia setjmp de funciones en libc reside en un miembro estático de libc, que significa que cada binario existente de AIX tiene una copia enlazada estáticamente de la familia setjmp y otros que existían con la versión de AIX con la que estaba enlazado. Además, los binarios existentes de AIX tienen definiciones de estructura de datos jmpbufs y ucontext que son insuficientes para alojar cualquier estado de registro de vector no volátil adicional.

Cualquier caso en el que los módulos heredados y los nuevos módulos intercalan llamadas, o llamadas de retroceso, en el que un módulo heredado podría realizar un longjmp () o setcontext (), eludiendo la convención de enlace normal de un módulo extendido de vector, tiene un riesgo de comprometer el estado de registro de vector no volátil.

Por este motivo, mientras que AIX ABI define registros de vectores no volátiles, la modalidad de compilación predeterminada cuando se utilizan vectores (AltiVec) en compiladores AIX es no utilizar ninguno de los registros de vectores no volátiles. Esto da como resultado un entorno de compilación predeterminado que permite de forma segura la explotación de vectores (AltiVec) al tiempo que no introduce ningún riesgo con respecto a la interoperatividad con los binarios heredados.

Para las aplicaciones en las que la interoperabilidad y la dependencia de módulos son completamente conocidas, se puede habilitar una opción de compilación adicional que permitirá el uso de registros vectoriales no volátiles. Este modo sólo se debe utilizar cuando todos los módulos y comportamientos heredados dependientes se conocen completamente y se entienden que no tienen ninguna dependencia de funciones como setjmp (), sigsetjmp (), _setjmp () o getcontext (), o cuando se garantiza que todas las transiciones de módulo se realizan utilizando la convención de enlace de subrutina normal, y que no se utilizan devoluciones de llamada a un módulo heredado en sentido ascendente.

El entorno de compilación AltiVec predeterminado predefine __VEC__, de acuerdo con el Manual de la interfaz de programación tecnológica deAltiVec.

Cuando la opción para utilizar registros de vectores no volátiles está habilitada, el entorno de compilación también debe predefinir __EXTABI__. Puede compilar módulos habilitados para no vectores para que se amplíen según ABI definiendo de forma explícita __AIXEXTABI. Esto garantizará que estos módulos puedan interactuar de forma segura con los módulos habilitados para vectores que están habilitados para utilizar registros de vectores no volátiles.

Contexto ampliado

Para dar soporte al estado de máquina adicional que requiere la extensión de vector, así como a otras extensiones como, por ejemplo, las claves de usuario, AIX 5.3 ha introducido soporte para estructuras de contexto ampliado. El uso visible de la aplicación primaria de la información de contexto de máquina es su presencia en la estructura de sigcontext proporcionada a los manejadores de señal, y la activación resultante del contexto de máquina en el sigcontext al retorno del manejador de señal. La estructura sigcontext es en realidad un subconjunto de la estructura ucontext más grande. Las dos estructuras son idénticas para hasta sizeof (struct sigcontext). Cuando AIX crea un contexto de señal para pasarlo a un manejador de señales, en realidad crea una estructura ucontext en la pila del manejador de señales. La porción de contexto de máquina de un contexto de señal debe contener todo el estado activo de la máquina, volátil y no volátil, para el contexto interrumpido involuntariamente. Para lograr esto sin afectar la compatibilidad binaria con los manejadores de señales existentes, el espacio previamente reservado en la estructura ucontext ahora sirve como una indicación de si la información de contexto ampliada está disponible.

Un campo recién definido en ucontext, __extctx, es la dirección de una estructura de contexto ampliada, struct __extctx, tal como se define en el archivo sys/context.h . Un nuevo campo, __extctx_magic, dentro de la estructura ucontext indica si la información de contexto ampliada es válida cuando el valor de __extctx_magic es igual a __EXTCTX_MAGIC. El estado de máquina de vector adicional para una hebra que utiliza la extensión de vector se guarda y se restaura como un miembro de esta nueva extensión de contexto a la estructura ucontext como una parte de la entrega y devolución de señal.

La estructura ucontext también se utiliza en las API (como getcontext (), setcontext (), swapcontext () y makecontext ()). En estos casos, el contexto que se debe guardar se debe a una acción voluntaria, para la que la convención de enlace de llamada sólo requiere que se guarde el estado de la máquina no volátil. Puesto que la modalidad predeterminada de habilitación de vectores en AIX, tal como se describe en la sección ABI, es no utilizar registros de vectores no volátiles, no hay extensiones de la estructura de ucontext necesarias para la mayoría de las aplicaciones. Si una aplicación opta por habilitar explícitamente el uso de registros vectoriales no volátiles, seleccionará una estructura ucontext de tamaño ampliado que ya tiene espacio para el campo __extctx que incluye la definición implícita de __EXTABI__ por parte del compilador. El ucontext ampliado también se puede seleccionar mediante una definición explícita de __AIXEXTABI.

De forma similar, jmp_buf para su uso con setjmp () o longjmp () no requiere ningún cambio para las aplicaciones habilitadas para vectores de modo predeterminado, ya que no se utilizan registros de vectores no volátiles. La habilitación explícita de registros de vectores no volátiles da como resultado asignaciones jmp_buf más grandes, debido a la definición implícita de __EXTABI__ por parte del compilador. Los almacenamientos intermedios de salto ampliados también se pueden activar mediante la definición explícita de __AIXEXTABI.

Consulte el archivo de cabecera sys/context.h para obtener un diseño más detallado de la información de contexto ampliada.

Asignación y alineación de memoria vectorial

Los tipos de datos vectoriales introducen un tipo de datos que requiere una alineación de 16 bytes. De acuerdo con la especificación de la interfaz de programación AltiVec , AIX proporciona un conjunto de subrutinas malloc (vec_malloc, vec_free, vec_realloc, vec_calloc) que proporcionan asignaciones alineadas de 16 bytes.

La compilación habilitada para vectores, con _VEC_ definido implícitamente por el compilador, dará como resultado que las llamadas a malloc y calloc heredados se redireccionen a sus contrapartes seguras para vectores, vec_malloc y vec_calloc, respectivamente. El código no vectorial también se puede compilar explícitamente para recoger estas mismas redirecciones malloc y calloc definiendo explícitamente __AIXVEC. La alineación de las asignaciones malloc (), realloc () y calloc () predeterminadas también se puede controlar en tiempo de ejecución.

MALLOCALIGN=16;  export MALLOCALIGN

La variable de entorno MALLOCALIGN se puede establecer en cualquier potencia de 2 mayor o igual que el tamaño de un puntero en la modalidad de ejecución correspondiente (4 bytes para la modalidad de 32 bits, 8 bytes para la modalidad de 64 bits). Si MALLOCALIGN se establece en un valor no válido, el valor se redondea a la siguiente potencia de 2, y todas las asignaciones de malloc () subsiguientes se alinearán con ese valor.

rc = mallopt(M_MALIGN, 16);

Consulte mallopt y MALLOCALIGN para obtener más información.

printf y scanf de tipos de datos vectoriales

De acuerdo con la especificación de la interfaz de programación AltiVec , se añade soporte a las versiones AIX de scanf, fscanf, sscanf, wsscanf, printf, fprintf, sprintf, snprintf, wsprintf, vprintf, vfprintf, vsprintf y vwsprintf para las nuevas series de formato de conversión de vector. Los nuevos formateadores de tamaño son los siguientes:

• vl o lv consume un argumento y modifica una conversión de enteros existente, lo que da como resultado int con signo de vector, int sin signo de vector o bool de vector para conversiones de salida o int con signo de vector * o int sin signo de vector * para conversiones de entrada. A continuación, los datos se tratan como una serie de cuatro componentes de 4 bytes, con el formato de conversión posterior aplicado a cada uno.
• vh o hv consume un argumento y modifica una conversión de entero corto existente, lo que da como resultado un vector con signo corto, o un vector sin signo corto para conversiones de salida o vector con signo corto * o vector sin signo corto * para conversiones de entrada. Los datos se tratan como una serie de ocho componentes de 2 bytes, con el formato de conversión posterior aplicado a cada uno.
• v consume un argumento y modifica un entero de 1 byte, un carácter de 1 byte o una conversión de coma flotante de 4 bytes. Si la conversión es una conversión de coma flotante, el resultado es vector float para la conversión de salida o vector float * para la conversión de entrada. Los datos se tratan como una serie de cuatro componentes de coma flotante de 4 bytes con el formato de conversión posterior aplicado a cada uno. Si la conversión es un entero o una conversión de caracteres, el resultado es vector signed char, vector unsigned char o vector bool char para la conversión de salida o vector signed char * o vector unsigned char * para las conversiones de entrada. Los datos se tratan como una serie de dieciséis componentes de 1 byte, con el formato de conversión posterior aplicado a cada uno.

Cualquier formato de conversión que se pueda aplicar a la forma singular de un tipo de datos de vector se puede utilizar con una forma de vector. Las conversiones de enteros %d, %x, %X, %u, %iy %o se pueden aplicar con las conversiones de enteros %lv, %vl, %hv, %vh, y %v calificadores de longitud de vector. La conversión de caracteres %c se puede aplicar con el calificador de longitud de vector %v. Las conversiones flotantes %a, %A, %e, %E, %f, %F, %gy %G se pueden aplicar con el calificador de longitud de vector %v.

Para las conversiones de entrada, se puede especificar un carácter separador opcional excluyendo el espacio en blanco que precede al separador. Si no se especifica ningún separador, el separador predeterminado es un espacio que incluye los caracteres de espacio en blanco que preceden al separador, a menos que la conversión sea c y, a continuación, la conversión predeterminada sea nula.

Para las conversiones de salida, se puede especificar un carácter separador opcional inmediatamente antes de la conversión de tamaño de vector. Si no se especifica ningún separador, el separador predeterminado es un espacio, a menos que la conversión sea c y, a continuación, el separador predeterminado sea nulo.

Aplicaciones con hebras

También se da soporte a las aplicaciones multihebra que explotan la extensión de vector. Estas aplicaciones están soportadas tanto en el ámbito del sistema (modelo de hebras 1: 1) como en el ámbito de proceso (modelo de hebras M: N). Si una aplicación multihebra se compila con registros vectoriales no volátiles habilitados, los pthreads de dicha aplicación se marcarán como pthreads ABI ampliados. El resultado serán asignaciones de almacenamiento intermedio de guardado de contexto más grandes dentro de la biblioteca pthread para esas hebras. El depurador dbx AIX también proporciona soporte completo para la depuración a nivel de máquina de programas multihebra habilitados para vectores.

Compiladores

Un compilador AIX que dé soporte a la extensión de vector debe ajustarse a AIX ABI Vector Extension. Como se ha descrito anteriormente, la modalidad de compilación habilitada para vectores predeterminada en AIX debe estar con el uso de registros de vectores no volátiles inhabilitado. Una opción explícita para habilitar el uso de registros vectoriales no volátiles se puede proporcionar y habilitar a su discreción, después de comprender los problemas y riesgos relacionados con la interoperabilidad del módulo nuevo y antiguo.

Al habilitar el uso de registros vectoriales no volátiles, un compilador C o C++ debe predefinir __EXTABI__. Además, cuando se habilita para cualquier forma de compilación de vector, se espera que un compilador C o C++ predefina __VEC__. Si se compilan módulos C o C++ no habilitados para vectores para el enlace con módulos Fortran habilitados para vectores, es mejor que los módulos C o C++ se compilen explícitamente con al menos __AIXVEC definido (definición explícita análoga a __VEC__), y también __AIXEXTABI (definición explícita análoga a __EXTABI) si los registros de vectores no volátiles están habilitados en los módulos Fortran .

Además de la especificación de la interfaz de programación AltiVec , que proporciona una extensión explícita a los lenguajes C y C++ para la programación vectorial, algunos compiladores probablemente permitirán la explotación de la extensión vectorial en algunos valores de optimización cuando se dirigen a un procesador que soporta la extensión vectorial.

Consulte la documentación del compilador para obtener más detalles.

ensamblador

El ensamblador de AIX , en el directorio /usr/ccs/bin/as , ahora soporta el conjunto de instrucciones adicional definido por la extensión de vector, y específicamente tal como lo implementa el procesador PowerPC 970 . Puede utilizar la nueva modalidad de ensamblaje -m970 o la pseudo operación .machine 970 dentro del archivo de origen para habilitar el ensamblaje de las nuevas instrucciones de vector. Consulte la publicación Assembler Language Reference para obtener más información.

Depurador

El depurador dbx AIX , en /usr/ccs/bin/dbx, da soporte a la depuración a nivel de máquina de programas habilitados para vectores. Este soporte incluye la capacidad de desensamblar las nuevas instrucciones vectoriales y de visualizar y establecer registros vectoriales. Se ha definido un nuevo valor de $instructionset de 970 para habilitar el desensamblado de las instrucciones específicas de PowerPC 970, incluidas las instrucciones de vector, cuando no se ejecuta dbx en un sistema PowerPC 970 . Tenga en cuenta que si ejecuta dbx en un PowerPC 970, el $instructionset predeterminado será 970.

Para ver registros de vector, se debe utilizar el subcomando unset $novregs, ya que los registros de vector no se visualizan de forma predeterminada. Además, si el procesador no soporta la extensión de vector, o el proceso o hebra que se está examinando no está utilizando la extensión de vector, no se mostrará ningún estado de registro de vector. De lo contrario, el subcomando de registros imprimirá todos los registros de vector y su contenido en hexadecimal sin formato.

También puede visualizar los registros vectoriales individualmente, formateados según un tipo fundamental. Por ejemplo, imprimir $vr0 mostrará el contenido del registro VR0 como una matriz de 4 enteros. print $vr0c mostrará el contenido del registro VR0 como una matriz de 16 caracteres. print $vr0s mostrará el contenido del registro VR0 como una matriz de 8 cortos, e print $vr0f mostrará el contenido del registro VR0 como una matriz de 4 flotantes.

Puede asignar registros de vector completos, por ejemplo, asignar $vr0 = $vr1, o asignar elementos de vector individuales del registro de vector como si se asignara un elemento de una matriz. Por ejemplo, asignar $vr0[3] = 0x11223344 establece sólo el 4th miembro entero de VR0. asignar $vr0f[0] = 1.123 da como resultado que solo el primer miembro flotante de VR0 se establezca en el valor 1.123.

Puede rastrear registros de vector durante la ejecución de una función o programa, por ejemplo tracei $vr0 en main mostrará el contenido de VR0 cada vez que se modifique en main (). Del mismo modo, al especificar uno de los registros de formato ($vr0f, $vr0c, $vr0s) en tracei, cada visualización del contenido se formateará en consecuencia.

Siempre que los compiladores representen tipos de datos vectoriales como matrices de sus tipos fundamentales, dbx también debería poder mostrar un tipo de datos vectorial formateado como matriz.

Consulte la documentación del mandato dbx para obtener más información.

La habilitación para depuradores de terceros también se proporciona en forma de PTT_READ_VEC y PTT_WRITE_VEC nuevas operaciones ptrace, para leer o escribir el estado de registro de vector para una hebra. Consulte la documentación de ptrace para obtener más detalles.

El sistema de archivos /proc también se ha mejorado para dar soporte a un depurador basado en /proc. Los archivos de estado y lwpstatus para un proceso y hebra habilitados por vector, respectivamente, se amplían para incluir el estado de registro de vector. Un nuevo mensaje de control, PCSVREG, está soportado en la grabación de un archivo de control de proceso o hebra para establecer el estado de registro de vector. Consulte la publicación /proc File Reference para obtener más detalles.

Archivos de núcleo

AIX también da soporte a la inclusión del estado de máquina vectorial como parte del archivo principal para un proceso o hebra habilitado para vectores. Sólo si un proceso o hebra está utilizando la extensión de vector se incluirá el estado de máquina de vector en la imagen de núcleo para esa hebra. Tenga en cuenta que si selecciona el formato de archivo principal previo aAIX 4.3 , el estado del vector no se incluirá. El estado de vector sólo está soportado en los formatos de archivo principales actuales. Puede utilizar el mandato dbx para leer y visualizar el estado de la máquina vectorial de un archivo principal habilitado para vectores.