x86 - ultima - ¿Por qué Intel oculta el núcleo RISC interno en sus procesadores?
ultima version de linux (6)
Comenzando con Pentium Pro (microarquitectura P6), Intel rediseñó sus microprocesadores y utilizó el núcleo RISC interno según las antiguas instrucciones de CISC. Desde Pentium Pro, todas las instrucciones CISC se dividen en partes más pequeñas (uops) y luego se ejecutan mediante el núcleo RISC.
Al principio, estaba claro para mí que Intel decidió ocultar la nueva arquitectura interna y forzar a los programadores a usar "shell CISC". Gracias a esta decisión, Intel pudo rediseñar completamente la arquitectura de los microprocesadores sin romper la compatibilidad, es razonable.
Sin embargo, no entiendo una cosa, ¿por qué Intel todavía mantiene un conjunto interno de instrucciones RISC oculto durante tantos años? ¿Por qué no dejarían que los programadores usen instrucciones RISC como el uso de las antiguas instrucciones x86 CISC?
Si Intel mantiene la compatibilidad con versiones anteriores durante tanto tiempo (todavía tenemos el modo 8086 virtual junto al modo de 64 bits), ¿por qué no nos permiten compilar programas para que omitan las instrucciones CISC y usen el núcleo RISC directamente? Esto abrirá una forma natural para abandonar lentamente el conjunto de instrucciones x86, que está en desuso en la actualidad (esta es la razón principal por la que Intel decidió usar el núcleo RISC en su interior, ¿no?).
En cuanto a la nueva serie Intel ''Core i'', veo que solo amplían las instrucciones CISC y agregan AVX, SSE4 y otros.
¿Por qué no nos permiten compilar programas para que omitan las instrucciones CISC y usen el núcleo RISC directamente?
Además de las respuestas anteriores, la otra razón es la segmentación del mercado. Se cree que algunas instrucciones se implementan en microcódigos más que en hardware, por lo que permitir que alguien ejecute microoperaciones arbitrarias puede socavar las ventas de nuevas CPU con "nuevas" instrucciones CISC más eficientes.
Si Intel mantiene la compatibilidad con versiones anteriores durante tanto tiempo (todavía tenemos el modo 8086 virtual junto al modo de 64 bits), ¿por qué no nos permiten compilar programas para que omitan las instrucciones CISC y usen el núcleo RISC directamente? Esto abrirá una forma natural para abandonar lentamente el conjunto de instrucciones x86, que está en desuso en la actualidad (esta es la razón principal por la que Intel decidió usar el núcleo RISC en su interior, ¿no?).
Necesitas mirar el ángulo comercial de esto. Intel realmente ha intentado alejarse de x86, pero es la gallina de los huevos de oro para la compañía. XScale e Itanium nunca estuvieron ni siquiera cerca del nivel de éxito que tiene su negocio principal de x86.
Lo que básicamente estás preguntando es si Intel cortará sus muñecas a cambio de tibios fuzzies de los desarrolladores. Socavar x86 no está en sus intereses. Cualquier cosa que haga que más desarrolladores no tengan que elegir apuntar a x86 socava x86. Eso, a su vez, los socava.
La respuesta de jalf cubre la mayoría de las razones, pero hay un detalle interesante que no menciona: el núcleo interno tipo RISC no está diseñado para ejecutar un conjunto de instrucciones como ARM / PPC / MIPS. El impuesto x86 no solo se paga en los decodificadores hambrientos de poder, sino hasta cierto punto en todo el núcleo. es decir, no es solo la codificación de la instrucción x86; son todas las instrucciones con una semántica extraña.
Imaginemos que Intel creó un modo operativo donde la secuencia de instrucciones no era x86, con instrucciones que se asignaban más directamente a uops. Supongamos también que cada modelo de CPU tiene su propio ISA para este modo, por lo que aún pueden cambiar las partes internas cuando lo deseen y exponerlas con una cantidad mínima de transistores para la decodificación de instrucciones de este formato alternativo.
Es de suponer que aún tendría el mismo número de registros, asignados al estado arquitectónico x86, por lo que los sistemas operativos x86 pueden guardarlo / restaurarlo en los conmutadores de contexto sin utilizar el conjunto de instrucciones específico de la CPU. Probablemente esto no sea demasiado difícil, ya que el hardware de cambio de nombre de registro ya existe. (Los uops internos realmente hacen referencia al archivo de registro físico, pero nuestro ISIS de RISC hipotético no debería).
Si solo tenemos decodificadores alternativos sin cambios en las etapas de la tubería posteriores (unidades de ejecución), esta ISA todavía tendría muchas excentricidades x86. No sería una arquitectura RISC muy agradable. Ninguna instrucción sería muy compleja, pero algunas de las otras locuras de x86 seguirían allí.
Por ejemplo: los cambios hacia la izquierda / derecha dejan indefinido el indicador de Desbordamiento, a menos que el recuento de turnos sea uno, en cuyo caso OF = la detección de desbordamiento con signo habitual. Locura similar para rota. Sin embargo, las instrucciones RISC expuestas podrían proporcionar cambios sin bandera y así sucesivamente (lo que permite el uso de uno o dos de los múltiples uops que generalmente entran en algunas instrucciones complejas de x86). Entonces esto realmente no se sostiene como el contraargumento principal.
Si vas a hacer un decodificador completamente nuevo para un RISC ISA, puedes hacer que escoja y elija partes de instrucciones x86 para que se expongan como instrucciones RISC. Esto mitiga algo la especialización x86 del núcleo.
La codificación de la instrucción probablemente no sea de tamaño fijo, ya que el uops único puede contener una gran cantidad de datos. Hay mucha más información de la que tiene sentido si todos los insns son del mismo tamaño. Un solo uop micro fusionado puede agregar un operando de memoria inmediata de 32 bits y un modo de direccionamiento con 2 registros y un desplazamiento de 32 bits. (En SnB y más tarde, solo los modos de direccionamiento de registro único pueden microfusionarse con operaciones de ALU).
Los uops son muy grandes y no muy similares a las instrucciones de ARM de ancho fijo. Un conjunto de instrucciones de 32 bits de ancho fijo solo puede cargar 16 bits inmediatos a la vez, por lo que cargar una dirección de 32 bits requiere un par inmediato de carga baja media / carga inmediata. x86 no tiene que hacer eso, lo que ayuda a que no sea terrible, con solo 15 registros GP que limitan la capacidad de mantener las constantes en los registros. (15 es una gran ayuda en 7 registros, pero doblar nuevamente a 31 ayuda mucho menos, creo que se encontró algo de simulación. RSP generalmente no es de propósito general, por lo que es más como 15 registros de GP y una pila).
TL; RD resumen:
De todos modos, esta respuesta se reduce a "el conjunto de instrucciones x86 es probablemente la mejor manera de programar una CPU que tenga que ser capaz de ejecutar instrucciones x86 rápidamente", pero con un poco de suerte aclara los motivos.
La respuesta es simple. ¡Intel no está desarrollando CPU para desarrolladores ! Los están desarrollando para las personas que toman las decisiones de compra , lo que por cierto, ¡es lo que hacen todas las empresas del mundo!
Hace mucho tiempo, Intel asumió el compromiso de que, (dentro de lo razonable, por supuesto), sus CPU seguirían siendo compatibles con versiones anteriores. La gente quiere saber que, cuando compran una nueva computadora basada en Intel, todo su software actual funcionará exactamente igual que en su computadora anterior. (Aunque, con suerte, ¡más rápido!)
Además, Intel sabe exactamente cuán importante es ese compromiso, porque una vez trataron de ir por un camino diferente. ¿Exactamente cuántas personas conoces con una CPU Itanium?!?
Puede que no le guste, pero esa única decisión, quedarse con el x86, es lo que hizo que Intel sea uno de los nombres comerciales más reconocidos en el mundo.
La verdadera respuesta es simple.
El principal factor detrás de la implementación de procesadores RISC fue reducir la complejidad y ganar velocidad. La desventaja de RISC es la densidad de instrucciones reducida, lo que significa que el mismo código expresado en formato RISC necesita más instrucciones que el código CISC equivalente.
Este efecto secundario no significa mucho si su CPU se ejecuta a la misma velocidad que la memoria, o al menos si ambos funcionan a velocidades razonablemente similares.
Actualmente, la velocidad de la memoria en comparación con la velocidad de la CPU muestra una gran diferencia en los relojes. Las CPU actuales a veces son cinco veces o más rápidas que la memoria principal.
Este estado de la tecnología favorece un código más denso, algo que proporciona CISC.
Se puede argumentar que las memorias caché pueden acelerar las CPU RISC. Pero lo mismo puede decirse sobre CISC cpus.
Obtiene una mayor velocidad de mejora al usar CISC y cachés que RISC y cachés, porque el mismo caché de tamaño tiene más efecto en el código de alta densidad que proporciona CISC.
Otro efecto secundario es que RISC es más difícil en la implementación del compilador. Es más fácil optimizar compiladores para CISC cpus. etc.
Intel sabe lo que están haciendo.
Esto es tan cierto que ARM tiene un modo de densidad de código más alto llamado Thumb.
No, el conjunto de instrucciones x86 definitivamente no está en desuso. Es tan popular como siempre. La razón por la cual Intel usa un conjunto de microinstrucciones similares a RISC internamente es porque se pueden procesar de manera más eficiente.
Entonces, una CPU x86 funciona teniendo un decodificador bastante resistente en la interfaz, que acepta instrucciones x86, y las convierte a un formato interno optimizado, que el servidor puede procesar.
En cuanto a exponer este formato a programas "externos", hay dos puntos:
- no es un formato estable. Intel puede cambiarlo entre modelos de CPU para adaptarse mejor a la arquitectura específica. Esto les permite maximizar la eficiencia, y esta ventaja se perdería si tuvieran que establecerse en un formato de instrucción fijo y estable para uso interno así como para uso externo.
- no hay nada que ganar al hacerlo. Con las enormes y complejas CPU actuales, el decodificador es una parte relativamente pequeña de la CPU. Tener que decodificar las instrucciones x86 hace que sea más complejo, pero el resto de la CPU no se ve afectado, así que, en general, hay muy poco que ganar, especialmente porque la interfaz x86 todavía tendría que estar allí, para poder ejecutar el código "heredado" . Así que ni siquiera guardarías los transistores actualmente utilizados en la interfaz x86.
Esta no es una disposición perfecta, pero el costo es bastante pequeño, y es una opción mucho mejor que diseñar la CPU para admitir dos conjuntos de instrucciones completamente diferentes. (En ese caso, probablemente terminen inventando un tercer conjunto de microoperaciones para uso interno, solo porque pueden ajustarse libremente para ajustarse mejor a la arquitectura interna de la CPU)