arm - significado - abi nombre
ARM ABI debe consultarse cuando se utiliza un puerto de kernel del sistema operativo en ARM.
EABI es cuando el procesador se inicia para cargar una aplicación sin núcleo intermedio. (Algo parecido a lo que solía ser ROM-BASIC cuando surgió DOS), es decir, el firmware en sí mismo es la aplicación independiente, no hay un monitor específico de la placa ni nada.
El primer enlace es a la subparte detallada relacionada con el procedimiento de llamadas de ARM ABI. A medida que el modelo de los programadores avanza con cada versión de ARM CPU, dichos temas son importantes y están cubiertos por ABI.
El segundo enlace trata sobre la especificación de formato binario para los archivos de objetos generados por el compilador llamado ELF, que está especificado por un proveedor de SO de la marca SCO. Quizás SCO es una organización de Santa Cruz que crea sus propios sabores de Unix y de Linux, sin embargo, esa historia se desvía de la pregunta. Debería estar interesado en esto si tiene la intención de implementar un enlazador que admita la ARM dirigida a ARM.
A menos que esté directamente preocupado por los detalles de implementación de la construcción de la cadena de herramientas para ARM, EABI debería ser de poca preocupación, y a menos que tenga en cuenta los aspectos específicos del SO de dicha cadena de herramientas, ARM ABI también debería ser de poca preocupación.
Un ABI ( Application Binary Interface ) es un estándar que define un mapeo entre conceptos de bajo nivel en lenguajes de alto nivel y las capacidades de un código de máquina de una plataforma de hardware / SO específica. Eso incluye cosas como:
- cómo los tipos de datos C / C ++ / Fortran / ... se presentan en la memoria (tamaños de datos / alineaciones)
- cómo funcionan las llamadas de funciones anidadas (dónde y cómo se almacena la información sobre cómo volver al llamante de una función, dónde se pasan los registros de la CPU y / o en la función de memoria)
- cómo funciona el inicio / inicialización del programa (qué formato de datos tiene un "ejecutable", cómo se carga el código / los datos desde allí, cómo funcionan los DLL ...)
Las respuestas a estas son:
- específico del idioma (por lo tanto, tiene un ABI de C, un ABI de C ++, un ABI de Fortran, un ABI de Pascal, ... incluso la especificación del código de bytes de Java, aunque está dirigido a un procesador "virtual" en lugar de hardware real, es un ABI),
- específico del sistema operativo (MS Windows y Linux en el mismo hardware usan un ABI diferente),
- hardware / CPU-específico (las ABI de ARM y x86 son diferentes).
- evolucionando a lo largo del (largo) tiempo (las ABI existentes a menudo se han actualizado / revisado para que las nuevas funciones de la CPU puedan utilizarse, como, por ejemplo, especificar cómo los registros SSE x86 deben ser utilizados por las aplicaciones, por supuesto, solo fue posible una vez Las CPU tenían estos registros, por lo tanto, las ABI existentes debían ser aclaradas).
Sin algún tipo de esta estandarización, el código (máquina) creado por diferentes compiladores no podría usar el mismo tipo de bibliotecas (¿cómo sabría usted de qué manera el código de la biblioteca espera que se pasen los argumentos de la función o las estructuras de datos?).
Cada plataforma (una combinación de hardware específico, software de sistema operativo y código escrito en lenguajes de programación específicos / compilados con compiladores específicos) define un conjunto completo de ABI para hacer que las cosas sean interoperables. La terminología en esta área no está clara, a veces las personas solo hablan sobre "el ABI", otras veces se llama el "complemento de plataforma", o uno menciona el lenguaje de programación y dice, por ejemplo, "el ABI de C ++". Tenga en cuenta, no hay una tal cosa.
Los documentos a los que se vinculó en su pregunta son ejemplos específicos de esto (ABI específicas del idioma / sistema operativo / hardware).
Incluso en una plataforma específica, no hay necesidad de tener un solo ABI (conjunto) porque diferentes convenciones pueden tener diferentes ventajas (y, por lo tanto, proporcionar un mejor rendimiento / un código más pequeño / un mejor uso de la memoria / ..., dependiendo del programa) y los diseñadores de sistemas usualmente tratan de ser flexibles / permisibles.
En Microsoft Windows de 32 bits, por ejemplo, hay una multitud de ABI (fastcall, stdcall, pascal, ...) para la función que llama a partes de la convención.
De todos modos, una búsqueda genérica de para "ABI" (que incluye los enlaces en la barra lateral "Relacionado") brinda tantas pistas para investigar esta pregunta que cierro mi respuesta en este momento.