¿Por qué Intel oculta el núcleo RISC interno en sus procesadores?

Si Intel mantiene la compatibilidad con versiones anteriores durante tanto tiempo (todavía tenemos modo 8086 junto al modo de 64 bits), Por qué no nos permiten compilar programas así que evitarán las instrucciones CISC ¿y usar RISC core directamente? Esta voluntad forma natural abierta para abandonar lentamente x86 conjunto de instrucciones, que está en desuso hoy en día (esta es la razón principal por Intel decidió usar el núcleo RISC dentro, ¿verdad?).

Usted necesita mirar el ángulo de negocio de esto. Intel tiene en realidad trató de alejarse de x86, pero es la gallina de los huevos de oro para la empresa. XScale e Itanium nunca estuvieron ni cerca del nivel de éxito que su negocio principal de x86 tiene.

Lo que básicamente estás pidiendo es que Intel se corte las muñecas a cambio de pelusas cálidas de los desarrolladores. Socavar a x86 no es de su interés. Cualquier cosa que haga que más desarrolladores no tengan que elegir el objetivo x86 socava a x86. Eso, a su vez, los socava.

La verdadera respuesta es simple.

El principal factor detrás de la implementación de los procesadores RISC fue reducir la complejidad y ganar velocidad. La desventaja de RISC es la densidad reducida de instrucciones, lo que significa que el mismo código expresado en formato RISC like 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 se ejecutan 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.

Puede argumentar que las cachés podrían acelerar las CPU RISC. Pero lo mismo puede decirse de las cpu CISC.

Se obtiene una mejora de velocidad mayor mediante el uso de CISC y cachés que RISC y cachés, porque el mismo tamaño de caché tiene más efecto en alta código de 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 cpu CISC. sucesivamente.

Intel sabe lo que están haciendo.

Esto es tan cierto que ARM tiene un modo de mayor densidad de código llamado Thumb.

La respuesta es simple. Intel no está desarrollando CPU para desarrolladores ! Los están desarrollando para las personas que toman las decisiones de compra , que POR cierto, es lo que hace cada empresa en el mundo!

Intel hace mucho tiempo se comprometió a 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, que todos de su software actual se ejecutará exactamente igual que lo hizo en su vieja computadora. (Aunque, con suerte, más rápido!)

Además, Intel sabe exactamente lo importante que 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 te guste, pero esa única decisión, permanecer con el x86, es lo que hizo de Intel uno de los nombres comerciales más reconocibles del mundo!

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 x86-tax no solo se paga en los decodificadores hambrientos de energía, sino hasta cierto punto en todo el núcleo. es decir, no es solo la codificación de instrucción x86; es cada instrucción con semántica extraña.

Imaginemos que Intel creó un modo de operación donde el flujo de instrucciones estaba algo que no sea x86, con instrucciones que se asignan más directamente a uops. También vamos a pretender que cada modelo de CPU tiene su propia ISA para este modo, por lo que todavía son libres de cambiar los internos cuando quieran, y exponerlos con una cantidad mínima de transistores para la instrucción-decodificación de este formato alternativo.

Presumiblemente solo 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 interruptores de contexto sin usar el Conjunto de instrucciones específicas de la CPU. Esto probablemente no sea demasiado difícil, ya que el hardware de cambio de nombre de registro ya existe. (los uops internos en realidad hacen referencia al archivo de registro físico, pero nuestro hipotético RISC ISA no tendría que hacerlo).

Si solo tenemos decodificadores alternativos sin cambios en etapas posteriores de la canalización (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 algunos de la otra locura de x86 todavía estaría allí.

Por ejemplo: los cambios izquierda/derecha dejan el indicador de desbordamiento indefinido, a menos que el recuento de cambios sea uno, en cuyo caso= la detección habitual de desbordamiento con signo. Locura similar para rotaciones. Sin embargo, las instrucciones RISC expuestas podrían proporcionar cambios sin bandera y así sucesivamente (permitiendo el uso de solo uno o dos de los múltiples uops que generalmente entran en algunas instrucciones x86 complejas). Así que esto realmente no se sostiene como el principal contra-argumento.

Si va a hacer un decodificador completamente nuevo para una ISA RISC, puede hacer que elija partes de las instrucciones x86 para que se expongan como instrucciones RISC. Esto mitiga un poco la especialización x86 del núcleo.

La codificación de la instrucción probablemente no sería de tamaño fijo, ya que un solo uops puede contener muchos datos. Mucho más datos de lo que tiene sentido si todos los insns son del mismo tamaño. Un solo uop micro-fusionado puede agregar un inmediato de 32 bits y una memoria operando que utiliza un modo de direccionamiento con 2 registros y un desplazamiento de 32 bits. (En SnB y posteriores, solo los modos de direccionamiento de registro único pueden micro fusible con ALU ops).

Las Uops son muy grandes y no muy similares a las instrucciones de BRAZO de ancho fijo. Un conjunto de instrucciones de 32 bits de ancho fijo solo puede cargar inmediates de 16 bits a la vez, por lo que cargar una dirección de 32 bits requiere un par carga-media baja inmediata / carga alta inmediata. x86 no tiene que hacer eso, lo que ayuda a que no sea terrible con solo 15 GP registros que limitan la capacidad de mantener constantes en los registros. (15 es una gran ayuda sobre 7 registros, pero doblar de nuevo a 31 ayuda mucho menos, creo que se encontró alguna simulación. RSP generalmente no es de propósito general, por lo que es más como 15 registros GP y una pila.)

TL; DR resumen:

De todos modos, esta respuesta se reduce a "el conjunto de instrucciones x86 es probablemente la mejor manera de programar una CPU que tiene que ser capaz de ejecutar instrucciones x86 rápidamente", pero con suerte arroja algunos luz en las razones.

¿Por qué no nos permiten compilar programas para evitar las instrucciones CISC y usar RISC core 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ódigo en lugar de en hardware, por lo que permitir que cualquiera ejecute microoperaciones arbitrarias puede socavar las ventas de nuevas CPU con "nuevas" instrucciones CISC más eficientes.