assembly - ¿Por qué las instrucciones ejecutadas condicionalmente no están presentes en los conjuntos de instrucciones ARM posteriores?
computer-architecture conditional-execution (7)
Las instrucciones ingenuas y condicionadas me parecen una gran idea.
A medida que leo más sobre los conjuntos de instrucciones ARM (y similares a ARM) (Thumb2, Unicore, AArch64), encuentro que a todos les faltan los bits para la ejecución condicional.
¿Por qué falta la ejecución condicional de cada uno de estos?
¿Fue la ejecución condicional un error en ese momento, o los cambios posteriores la convirtieron en una costosa pérdida de bits de instrucción?
"¿Por qué las instrucciones ejecutadas condicionalmente no están presentes ..." "¿Fue un error la ejecución condicional en ese momento, o los cambios subsiguientes lo convirtieron en una costosa pérdida de bits de instrucciones?"
[Respuesta parcial, autor asociado con la idea (y un proponente de la misma)]
Elección de diseño Agrega características y expandes tus posibilidades; elimínalos y podrás implementar soluciones alternativas, o prescindir de ellas.
Costo, TDP y Patentes, incluso el nivel de habilidad técnica necesario para desarrollar un producto de la competencia entra en juego.
Hay miles de millones en la mesa, cuando lanzas esos dados no quieres rodar todo el Negocio, así que ellos eligen no hacerlo.
En mi opinión, es un error omitir la capacidad de Elison en un Procesador de Servidor que se fija a un Fabric, pero estoy parcializado.
No es un error (tenerlo bien implementado), es caro, no es un desperdicio (los bits son inteligentes y se ocupan de sus propios asuntos).
Es como cualquier extensión de CPU, o agregar una GPU; Si puede hacer un uso hábil de sus herramientas, entonces estará listo, de lo contrario empacar la luz.
Cita de Wikipedia: "Según diferentes puntos de referencia, TSX puede proporcionar un 40% más rápido de ejecución de aplicaciones en cargas de trabajo específicas, y 4 a 5 veces más transacciones de base de datos por segundo (TPS)".
Es ''costoso'' (para algunas situaciones) pero importante para el estilo actual de programación, o más pesimista, un medio para obtener puntuaciones mucho más altas en los puntos de referencia sintéticos.
Algún día será tan fácil como Lego, y usted podrá pedirle que se junte y haga su pedido; hasta entonces, el Procesador DEBE admitir la pereza del programador (y los compiladores de compiladores), por lo tanto, la rareza de los programas que se pueden ejecutar principalmente en la GPU (pero lo estamos logrando).
Por lo tanto, la eliminación de (grandes) características que se consideran no deseadas o no se implementaron de manera rentable y competitiva.
Así, las reglas de TSX actualmente; Pero las CPUs ARM también necesitan hilos de fantasía para su Fabric.
Referencias de URL:
AMD: https://en.wikipedia.org/wiki/Advanced_Synchronization_Facility
Intel: https://en.wikipedia.org/wiki/Transactional_Synchronization_Extensions
.
Al igual que, la ranura de aplazamiento en mips es un truco (en ese momento), la ejecución condicional en el brazo es un truco (en ese momento), al igual que la PC con dos instrucciones por delante. Ahora en el camino, ¿cuánto efecto tienen? ¿Será que el predictor de rama de ARM realmente hará esa gran diferencia o es la respuesta real que necesitaban más bits en una palabra de instrucción de 32 bits y, como el pulgar, la primera y la más fácil de eliminar es la condición de los bits?
no es demasiado difícil hacer algunas pruebas de rendimiento para ver qué tan bueno o nuevo es el predictor de ramificación, lo probé con ramificaciones incondicionales en un brazo11, dado que ahora es una arquitectura antigua pero de uso generalizado. Fue difícil, en el mejor de los casos, lograr que la predicción de la rama mostrara alguna mejora, y de ninguna manera, la forma o la forma podrían competir con la ejecución condicional. No he repetido esta experiencia en nada en la corteza, una familia.
En el antiguo ARM v4, las instrucciones condicionales solo ahorraban tiempo si había una alta probabilidad de que terminaran siendo ejecutadas, o si la probabilidad era de alrededor del 50%, entonces si solo había 2 a 4 de ellas seguidas. Si no estaban siendo ejecutados, entonces era una pérdida de ciclos tener que ir más allá de ellos, en lugar de usar una rama para superarlos. Si estuvieran siendo ejecutados, la rama sería recuperada pero no ejecutada.
Una pequeña molestia es que al realizar la depuración, la interrupción de una instrucción condicional siempre resultó en una interrupción de esa instrucción, independientemente de la condición (a menos que exista un depurador realmente inteligente que mi empresa no tenía).
Es un tanto engañoso decir que la ejecución condicional no está presente en ARMv8. El problema es entender por qué no quieres ejecutar algunas instrucciones. Quizás en los primeros días de ARM, la no ejecución real de las instrucciones era importante (para poder o lo que sea), pero hoy en día el significado de esta función es que le permite evitar las ramas para pequeños saltos tontos, por ejemplo, código como a = (b> 0? 1: 2). Este tipo de cosas es más común de lo que podría imaginar: conceptualmente son cosas como MAX / MIN o ABS (aunque para algunas CPU puede haber instrucciones para realizar estas tareas en particular).
En ARMv8, si bien no hay instrucciones generales que se ejecuten condicionalmente, hay algunas instrucciones que realizan la tarea específica que estoy describiendo, es decir, que le permite evitar las ramificaciones para saltos cortos y estúpidos; CSEL es el ejemplo más obvio, aunque existen otros casos (por ejemplo, el establecimiento de condiciones condicionales) para manejar otros patrones comunes (en ese caso, el patrón de evaluación de la expresión en cortocircuito en C).
En mi humilde opinión lo que ARM ha hecho aquí es lo que tiene más sentido. Han extraído la característica de ejecución condicional que sigue siendo valiosa en las CPU modernas (evita muchas ramas) al tiempo que cambian los detalles de la implementación para que coincidan con la microarquitectura de las CPU modernas.
La afirmación general es que los sistemas modernos tienen mejores predictores de ramificación y los compiladores son mucho más avanzados, por lo que su costo en el espacio de codificación de instrucciones no está justificado.
Esto es de la descripción general del conjunto de instrucciones ARMv8
El conjunto de instrucciones A64 no incluye el concepto de ejecución predicada o condicional. La evaluación comparativa muestra que los predictores de rama modernos funcionan lo suficientemente bien como para que la ejecución predicada de instrucciones no ofrezca beneficios suficientes para justificar su uso significativo del espacio de código de operación y su costo de implementación en implementaciones avanzadas.
Y sigue
Se proporciona un conjunto muy pequeño de instrucciones de "procesamiento de datos condicionales". Estas instrucciones se ejecutan incondicionalmente, pero utilizan los indicadores de condición como una entrada adicional a la instrucción. Se ha demostrado que este conjunto es beneficioso en situaciones donde las ramas condicionales predicen mal o son ineficientes.
Otro documento titulado Trading Conditional Execution for More Registers sobre los procesadores ARM afirma:
... la ejecución condicional ocupa un valioso espacio de instrucciones a medida que las condiciones se codifican en un selector de código de condición de 4 bits en cada instrucción ARM de 32 bits. Además, solo los pequeños porcentajes de instrucciones están condicionados en las aplicaciones integradas modernas, y la ejecución condicional ni siquiera puede llevar a una mejora del rendimiento en los procesadores integrados modernos.
La ejecución condicional es una buena opción en la implementación de muchas rutinas auxiliares o de manipulación de bits, como la clasificación, la manipulación de listas o árboles, la conversión de números a cadenas, la división sqrt o larga. Podríamos agregar controladores UART y extraer campos de bits en los enrutadores. Esos tienen una alta proporción de rama a rama, con una alta impredecibilidad también.
Sin embargo, una vez que supere el nivel más bajo de servicios (o aumente el nivel de abstracción utilizando un lenguaje de nivel superior), el código se ve completamente diferente: los bloques de código dentro de diferentes ramas de condiciones consisten más en mover datos y llamar a subrutinas. Aquí los beneficios de esos 4 bits adicionales se desvanecen rápidamente. No es solo desarrollo personal sino también cultural: la programación cultural ha crecido desde no estructurada (Basic, Fortran, Assembler) hacia estructural. Los diferentes paradigmas de programación se soportan mejor también en diferentes arquitecturas de conjuntos de instrucciones.
Un compromiso tecnológico podría haber sido la posibilidad de comprimir el campo ''cond.S'' de cinco bits en cuatro o tres combinaciones utilizadas con mayor frecuencia .
Una de las razones es que debido a la codificación.
En resumen , no puede comprimir más 4 bits en el espacio reducido de 16 bits, mientras que ni siquiera hay suficiente espacio para los 3 bits más altos de los registros y deben reducirse a un subconjunto de solo 8 registros. Tenga en cuenta que en thumb2 tiene una instrucción IT(E) separada para seleccionar las condiciones para las siguientes 4 instrucciones . Sin embargo, no puede almacenar la condición en la misma instrucción, debido a la razón mencionada anteriormente.
Para AArch64, el número de registros se ha duplicado en comparación con el ARM de 32 bits, pero nuevamente no queda ningún bit restante para los 3 nuevos bits altos de los registros. Si desea utilizar la codificación anterior, debe "tomar prestado" de la condición inmediata de 12 bits o de 4 bits. 12 bits es demasiado pequeño en comparación con otras arquitecturas RISC como MIPS y reducirlo empeora todo, por lo que eliminar la condición es una mejor opción. Debido a que la predicción de rama se ha vuelto más y más avanzada, no será un gran problema