¿Qué podría "perder" C/C++ si definieran un ABI estándar?

Compatibilidad con versiones anteriores en todas las plataformas excepto en la que se eligió ABI.

Las especificaciones del lenguaje C (o C++) definen el lenguaje fuente. No les importa que el procesador lo ejecute (un programa C podría incluso ser interpretado por un esclavo humano, pero eso sería poco ético y no rentable).

El ABI es por definición algo sobre el sistema de destino. Está relacionado con el procesador y el sistema (y las bibliotecas existentes después de la ABI).

En el pasado, sucedió que algunos procesadores tenían propietarios (es decir, no revelados) especificación (incluso su conjunto de instrucciones de máquina no era público), y tenían un ABI no público que era seguido por un compilador (respetando más o menos el estándar del lenguaje).

Definir un lenguaje de programación no requiere las mismas habilidades que definir el ABI.

^{Incluso podría definir una ABI más nueva para un procesador existente, pero eso requiere mucho trabajo (parchear el compilador, recompilar todo, incluidas las bibliotecas estándar de C & C++ y todas las utilidades y bibliotecas que usted necesita) por lo que es generalmente inútil.}

En lugar de un ABI genérico para todas las plataformas (lo que sería desastroso ya que solo sería óptimo para una sola plataforma). El comité de la norma podría decir que cada plataforma se ajustará a un ABI específico.

Pero: ¿Quién lo define (el primer compilador a través de la puerta?). En cuyo caso obtienen una ventaja competitiva excesiva. O un comité después de 5 años de compiladores (que sería otra idea horrible).

Tampoco le da al compilador un margen para hacer más si investigas nuevas estrategias de optimización, te quedarás atascado con los trucos disponibles en el punto donde se definió el estándar.

La velocidad de ejecución sufriría drásticamente en la mayoría de las plataformas. Tanto es así que probablemente ya no sería razonable usar el lenguaje C para una serie de plataformas integradas. El organismo de normalización podría ser responsable de una demanda antimonopolio presentada por los fabricantes de los diversos chips no compatibles con el ABI.

Bueno, no habría un ABI estándar, sino alrededor de 1000. Necesitaría uno para cada combinación de arquitectura de sistema operativo y procesador.

Inicialmente, nada se perdería. Pero eventualmente, alguien encontraría algún error horrible y lo arreglaría, rompiendo el ABI, o lo dejaría, causando problemas.

Creo que la situación en este momento está bien. Cualquier sistema operativo es libre de definir un ABI por sí mismo (y lo hacen), lo cual tiene sentido. Debe ser el trabajo del sistema operativo definir su ABI, no el estándar C/C++.

Básicamente, todo el mundo se perdió que una de las propuestas de C++14 realmente definía un ABI estándar. Era un ABI estándar específicamente para bibliotecas que usaban un subconjunto de C++. Se definen secciones específicas del código" ABI " (como un espacio de nombres) y se requiere que se ajusten al subconjunto.

No solo eso, fue escrito por Herb Stutter, experto en C++ y autor de la serie de libros "Exceptional C++".

La propuesta entra en muchas razones por las que un ABI portátil es difícil, así como soluciones novedosas.

Https://isocpp.org/blog/2014/05/n4028

Http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4028.pdf

Tenga en cuenta que define una "plataforma de destino" como una combinación de arquitectura de CPU (x64, x86, ARM, etc.), SO y bitness (32/64).

Así que el objetivo aquí, es realmente tener código C++ (Visual Studio) ser capaz de hablar con otro código C++ (GCC, Visual Studio más antiguo, etc.) en la misma plataforma. No es una meta de un ABI universal eso permite que las bibliotecas de teléfonos celulares se ejecuten en su máquina Windows.

Esta propuesta NO fue ratificada en C++14, sin embargo, fue trasladada a la fase de "Evolución" de C++17 para mayor discusión/iteración.

Https://www.ibm.com/developerworks/community/blogs/5894415f-be62-4bc0-81c5-3956e82276f3/entry/c_14_is_ratified_the_view_from_the_june_2014_c_standard_meeting?lang=en

Así que a partir de enero de 2017, mis dedos permanecen cruzados.

C siempre tenía un ABI estándar, que es incluso el que se usa para cualquier ABI más estándar (quiero decir, el ABI de C es el ABI de elección, cuando diferentes lenguajes o sistemas tienen que vincularse entre sí). El C ABI es una especie de ABI común de otros ABIs. C++ es más complejo aunque se extiende y por lo tanto se basa en C, y de hecho, un ABI estándar para C++ es más desafiante y puede presentar problemas para la libertad que un compilador de C++ tiene para su propia implementación del código máquina de destino. Sin embargo, parece que en realidad tienen un ABI estándar; ver Itanium C++ ABI .

Así que la pregunta puede no ser tanto "¿qué podrían perder?", sino más bien " what do they loose?"(si alguna vez realmente pierden algo).

Nota al margen: es necesario tener en cuenta que las ABI siempre dependen de la arquitectura y del sistema operativo. Así que si lo que se entiende por "Estándar ABI" es "estándar a través de arquitecturas y plataformas", entonces puede que nunca haya habido o haya tal cosa, sino protocolos de comunicación.