terminology - interfaz - ¿Qué es ABI(Application Binary Interface)?
abi interfaz binaria de aplicación (3)
Bueno, el concepto de ABI fue presumiblemente concebido para soportar la compatibilidad binaria de su programa en otros sistemas operativos y arquitecturas de máquinas. Entonces, supongamos que usted escribió un programa en alguna distribución del sistema operativo que se ejecuta en la arquitectura x86. Ahora, para un programador, lo más importante es que este programa que usted escribió en su máquina debería poder ejecutarse exactamente igual en cualquier otra máquina que se ejecute en la misma arquitectura o en otra diferente, por el bien de la discusión de que la otra máquina está funcionando. en la arquitectura i386 y aquí es donde entra en juego el concepto de ABI o Application Binary Interfaces. Como cada arquitectura de máquina define su propia manera en que el sistema operativo kernal se comunica con el mundo exterior, es decir, los programas de espacio de usuario, por lo tanto, cada arquitectura define un conjunto diferente de llamadas al sistema, registros de la máquina, cómo se utilizan esos registros, cómo se manejan las interrupciones del software por el núcleo, etc. ABI es lo que maneja estas cosas para usted, como compilar, vincular, ordenar bytes, etc. Los programadores de sistemas han tenido mucha suerte al definir un ABI uniforme para los mismos sistemas operativos que se ejecutan en diferentes arquitecturas y es por eso que cada arquitectura de máquina tiene la suya y usted necesita compilar sus programas para confirmar el formato que tienen esas máquinas.
Esto es lo que dice wikipedia:
En el software de computadora, una interfaz binaria de aplicación (ABI) describe la interfaz de bajo nivel entre un programa de aplicación (o cualquier tipo de) y el sistema operativo u otra aplicación.
Los ABI cubren detalles como el tipo de datos, el tamaño y la alineación; la convención de llamada, que controla cómo se pasan los argumentos de las funciones y se recuperan los valores de retorno; los números de llamada del sistema y cómo una aplicación debe hacer llamadas del sistema al sistema operativo; y en el caso de un sistema operativo completo ABI, el formato binario de archivos de objetos, bibliotecas de programas, etc. Un ABI completo, como el Estándar de compatibilidad binaria de Intel (iBCS), permite que un programa de un sistema operativo que soporta ese ABI se ejecute sin modificaciones en cualquier otro sistema, siempre que estén presentes las bibliotecas compartidas necesarias y se cumplan requisitos previos similares.
Supongo que un ABI es una convención o estándar, y los compiladores / enlazadores usan esta convención para producir códigos de objeto. ¿Está bien? Si es así, ¿quién hizo estas convenciones (empresas o alguna organización)? ¿Cómo fue cuando no había ABIs? ¿Hay documentos sobre estas ABI que podamos consultar?
La especificación es un término más adecuado que la convención, ya que la convención es un término vago para una práctica ampliamente aceptada, mientras que la especificación está bien definida.
Tienes razón. La especificación es realizada por el organismo de normalización. Eche un vistazo a la especificación POSIX que es compatible con Windows y las cadenas de herramientas de compilación / compilación como gcc asume que los sistemas operativos se adhieren a ella, e incluso el kernel de Linux se adhiere parcialmente (casi exactamente) a ella.
Antes de los ABIs? Incluso hoy en día, el firmware está hecho a mano a medida que aparecen nuevos chips para decodificadores y otros dispositivos que tienen sistemas integrados.
La documentación es contenido de lógica digital en la hoja de datos para los chips que se programarán por lenguaje ensamblador y para un lenguaje de nivel superior, la documentación de la cadena de herramientas de compilación cruzada revela las suposiciones que deben ser parte de ABI.
Tienes razón sobre la definición de un ABI, hasta cierto punto. El ejemplo clásico es la interfaz syscall en Linux (y otros UNIX).
Son una forma estándar para que el código solicite al sistema operativo que realice ciertas tareas.
Como tales, las deciden las personas que escribieron el SO o, en el caso de que las syscalls se hayan agregado más tarde, quien las haya agregado (en los casos en que el SO lo permita). Por ejemplo, la interfaz de Linux syscall en x86 indica que carga el número de syscall en eax , con otros parámetros colocados en ebx , ecx , etc., dependiendo de la syscall que esté realizando ( eax ).
Por lo general, no es el compilador o el enlazador los que hacen el trabajo de interconexión, sino que son las bibliotecas proporcionadas para el idioma que está utilizando.
Al volver a Linux, las bibliotecas de GNU C contienen código para fopen (por ejemplo) que finalmente llama a la syscall relevante para realizar las tareas de nivel inferior (syscall número 5, open ). Una lista de los syscalls se puede encontrar en este archivo PDF .