Por lo tanto, necesito hacer un proyecto completo en código crítico en su mayoría en el tiempo. Por lo tanto, usar el ensamblaje parece una buena idea.
Esa es una proposición falsa. ¿Está diciendo que no hay una sola secuencia de instrucciones en el código que se ejecuta solo una vez? Si el código pasa el 90% de su tiempo en el 10% del código, entonces la mayor parte del beneficio de velocidad al escribirlo en lenguaje ensamblador será el que se gastó en esas líneas de código del 10%. Reescribir el 90% restante solo traerá rendimientos decrecientes.
Ahora lo anterior se aplica a velocidad . El tamaño del código no sigue la regla 90/10: un programa gasta el 100% de su tamaño en el 100% del código. Una palabra guardada en cualquier lugar a lo largo de la longitud del programa hace que sea una palabra más corta. La mejor manera de justificar la codificación de todo en el ensamblaje es que tenga que ser lo más pequeño posible. Pero eso puede impedir que sea lo más rápido posible. Por ejemplo, no puede desenrollar los bucles si el código debe ser lo más pequeño posible. O funciones de relleno u otros objetivos de rama para alinearlos con líneas de caché.
La conversión a un estilo diferente de lenguaje ensamblador es trivial. No es nada como, digamos, traducir un programa de Haskell a C. No hay semántica involucrada, ni siquiera una sintaxis profunda. Es transliteración , no traducción , así que supéralo. La sintaxis del ensamblador GNU es perfectamente utilizable para la codificación humana y lo bueno es que brinda cierto tipo de coherencia en diferentes arquitecturas, que apreciará si pasa de ARM a MIPS, a SPARC, a ... De todos modos, ¿por qué? ¿Esperas sintaxis de Intel para una CPU que no es Intel x86?
Rant: ¿Sintaxis de Intel? Vamos, tiene una palabrería insípida como DWORD PTR que puede condensarse en un sufijo de una letra. La sintaxis x86 de Intel es la COBOL de la programación en lenguaje ensamblador.