¿C tiene un ABI estándar?

C no tiene ABI estándar en principio, pero en la práctica, esto rara vez importa: Usted hace lo que hace su proveedor de sistema operativo.

Tomemos las convenciones de llamada en Windows x86, por ejemplo: La API de Windows utiliza la llamada convención de llamada 'estándar' (stdcall). Por lo tanto, cualquier compilador que quiera interactuar con el sistema operativo debe implementarlo. Sin embargo, stdcall no admite todas las características del lenguaje C90 (por ejemplo, llamar a funciones sin prototipos, funciones variádicas). Como Microsoft proporcionó un compilador de C, un la segunda convención de llamadas era necesaria, llamada convención de llamadas ' C ' (cdecl). La mayoría de los compiladores de C en Windows usan esto como su convención de llamada predeterminada, y por lo tanto son interoperables.

En principio, lo mismo podría haber sucedido con C++, pero como la ABI de C++ (incluida la convención de llamadas) es necesariamente mucho más elaborada, los proveedores de compiladores no estuvieron de acuerdo en una sola ABI, pero aún podrían interoperar volviendo a extern "C".

Un ABI, incluso para C, tiene partes que son bastante independientes de la plataforma, partes que dependen del procesador (que registros deben guardarse, que se utilizan para pasar parámetros,...) y partes que dependen del sistema operativo (más o menos los mismos factores que para el procesador, ya que algunas opciones no son impuestas por la arquitectura sino que son el resultado de compensaciones, además de que algunos sistemas operativos tienen una noción de excepción independiente del lenguaje, por lo que un compilador para cualquier lenguaje tiene que generar lo correcto para manejar aquellos, el manejo de hilos también puede imponer cosas en el ABI if si un registro apunta a TLS, no puede usarlo para lo que desea).

En teoría, cada compilador puede tener su propia ABI. Pero por lo general, para un par de procesadores/sistemas operativos, el ABI es arreglado por el proveedor del sistema operativo que a menudo también proporciona un compilador de C y bibliotecas comunes que utilizan que ABI y los competidores prefieren ser compatibles. (No me sorprendería si hay excepciones para algunos sistemas operativos para los que C no es una programación importante idioma).

Pero el proveedor del sistema operativo puede cambiar ABI por una razón u otra (las nuevas versiones de procesadores pueden tener características que desee usar en el ABI para uno - por ejemplo, algunos han pedido un ABI de 32 bits para x86_64 que permita usar todos los registros). Durante la fase de migración, que puede durar mucho tiempo, es posible que tenga que manejar dos ABI.

El ABI para C es específico de la plataforma: cubre cuestiones como la asignación de registros y las convenciones de llamada, que obviamente son específicas de un procesador en particular. Estos son algunos ejemplos:

• El BRAZO ABI (incluye C++)
• El PowerPC Embebido ABI
• Los varios ABIs de x86

X86 ha tenido muchas convenciones de llamada, que extensiones bajo Windows para declarar cuál se utiliza. Plataforma ABIs para Linux embebido también tienen cambiado con el tiempo, lo que conduce a un espacio de usuario incompatible. Vea un poco de historia del port Linux ARM aquí, que muestra los problemas en la transición a una nueva ABI.

Tampoco C, ¿verdad?
Derecha

En cualquier plataforma, prácticamente lo hace. No sería útil como lingua franca para la comunicación inter-lingüística si careciera de una.
Bastante podría referirse a los valores predeterminados específicos de la arquitectura elegidos por los proveedores de compiladores de C que se adaptan a otros lenguajes. Así que si el compilador ARM C de Keil usará de izquierda a derecha little endian parameter ordering and stack para pasar argumentos y algún registro predeterminado para el valor de retorno, entonces extern " C " de otros compiladores asumirá compatibilidad con tal esquema.

Si bien tal acuerdo tal vez se considere parte de ABI, a diferencia del contexto de ejecución administrada como JVM browser sandbox, esto está lejos de ser ABI estándar completo por sí mismo.

Aunque varios intentos han sido hecho en la definición de un único ABI para un arquitectura dada a través de múltiples sistemas operativos (Particularmente para i386 en sistemas Unix), los esfuerzos no se han reunido con tal éxito. En cambio, los sistemas operativos tienden a definir sus propios ABIs ...

Citando ... Programación del sistema Linux página 4.

C no tiene un ABI estándar. Esto se ilustra fácilmente por todas las convenciones de llamada (cdecl, fastcall y stdcall) que se utilizan allí. Cada uno es un ABI diferente.

Antes del Estándar C89, los compiladores de C para muchas plataformas usaban esencialmente el mismo ABI, excepto por las variaciones en el tamaño de los datos. Para máquinas cuya pila crece hacia abajo, el código que llama a una función empujaría los argumentos en la pila en orden de derecha a izquierda y luego llamaría a la función (empujando la dirección de retorno en el proceso). Una función llamada dejaría sus argumentos en la pila, y la persona que llama a su ocio ajustar el puntero de pila para eliminarlos [o, en algunos arquitecturas, podría ajustar los valores apilados en su lugar]. Si bien <stdarg.h> hizo innecesario que la mayoría de los programas se basaran en esa convención, permaneció en uso durante muchos años porque era simple y funcionaba bastante bien. Si bien no había un documento "oficial" que estableciera eso como un "estándar" multiplataforma, la mayoría de los compiladores que se dirigían a máquinas con pilas que crecían hacia abajo funcionaban de esa manera, lo que conducía a un mayor nivel de consistencia que el que existe hoy en día.