Cuando Intel quiso matar al x86 (y fracasó en el intento)

¿Quién querría matar a su producto estrella? Usualmente nadie, pero Intel lo intentó al menos tres veces y fracasó en el intento.

Esta extraña historia tiene sus motivaciones, la realidad es que la arquitectura x86 tiene muchísimas limitaciones de diseño, de performance y siguió sosteniendo compatibilidad hacia sistemas antiguos durante toda su vida, algo que la hizo compleja. 

Recién ahora, en 2024, muchas de esas capas "legacy" quedarán obsoletas y lo antiguo dependerá de la virtualización, pero luego de tantos años era hora.

Intel trató varias veces de reemplazar el x86 con un diseño más avanzado, más potente o más eficiente, pero siempre falló. Curiosamente es otra arquitectura la que le ganó el lugar, ARM, con un criterio totalmente distitnto y logrando todos esos cambios que desde Intel también pretendían.

iAPX432

El primer intento es tan viejo como el 8080 mismo, un proyecto ambicioso y complejo de fines de los 70s donde se buscaba que el procesador fuera mucho más avanzado y resolviera muchas cosas para los programadores directamente desde la lógica del CPU.

Demasiado adeltantado a su época el iAPX432 era un CPU multi-chip, de 32 bits "MicroMainframe", incluía hasta un garbage collector, tolerancia a fallas, y soporte para programación de objetos prometiendo multiprocesamiento en clusters de hasta 63 nodos. Todo esto en plena época de PC XT, claro.

Fue desastroso, a mismo clock que un 286 ejecutaba a un cuarto de velocidad, había muchos problemas especialmente en el hardware y los compiladores. Pues resulta que había un problema a la hora de predecir qué se debía ejecutar y cuándo tomarlo de caché, las instrucciones hacían complejo programar ya que es difícil optimizar cuando uno está programando en alto nivel como se esperaba en el 432.  Ni siquiera C ejecutaba rápido en el CPU. Era tan complejo que tuvieron que separarlo en dos chips!

Por suerte para Intel, mientras gastaban un dineral desarrollando este procesador, un par de ingenieros, John Crawford y Pat Gelsinger siguieron con el desarrollo del 80286 de 16 bits para transformarlo en 32 bits y así nació el 80386, la salvación de Intel.

Muchos de los avances técnicos del 432 fueron a parar a los 386 y 486 especialmente todo lo que hubo que aprender sobre el manejo de memoria.

Curiosamente el 432 evolucionó en el i960 para sistemas embebidos, metiendo todos los chips en un sólo paquete y funcionó bastante bien en ese mercado durante 20 años sin siquiera ser conocido.

i860

Años después Intel se dio cuenta que el negocio de los procesadores CISC estaba en riesgo contra la arquitectura RISC así que en 1992 lanzó un procesador nuevo en paralelo al 486DX2, el i860.

¿Dos conceptos totalmente distintos de parte del mismo fabricante? Así es, pero inmediatamente se dieron problemas, para empezar el mercado no entendía a dónde apuntaba Intel  ¿Dos procesadores y que el mercado decida? Confuso, el x86 tenía tanto software a disponibilidad que hacía la elección trivial. El i860 no tenía software alguno a disposición. Era el huevo o la gallina en su caso.

Por otra parte el mercado RISC ya tenía unos cuantos competidores muy bien posicionados compitiendo etre sí: SGI con los MIPS, DEC con los Alpha, HP con los PA-RISC y hasta IBM pronto con los Power, no es que hubiese demasiado espacio si no había un diferencial notable. El software no lo era.

Para sumar un tercer golpe, los compiladores tenían problemas para optimizar el código para esta arquitectura, al final encontró nichos interesantes procesando gráficos y en tareas de DSP, era casi como un GPU hecho CPU y eso le dio un mercado de nicho. Para uso general era una carreta lenta, tardando una eternidad pasando entre tareas.

¿Aprendieron algo de esto? Pues sí, de aquí nacieron las extensiones MMX que luego se incluyeron en los Pentium en 1996.

Itanium

El tercer gran fracaso tal vez podría haberse evitado, pero Intel tenía esa manía de querer reinventar a pura ingeniería la rueda. El Itanium (también conocido como Itanic).

Tanto creyeron que la nueva arquitectura IA-64 iba a reemplazar al x86 que ni siquiera se pusieron a trabajar en una conversión a 64 bits del viejo y conocido x86, en cambio un rival menor, AMD, puso manos a la obra lentamente.

Para la llegada de ltanium los grandes fabricantes de procesadores RISC de servidores habían capitulado, todo era x86 para consumidor y luego Itanium para servidores, con semejante apoyo de grandes como DEC, HP, SGI y Sun nada podria fallar, IBM seguría sola con sus propios Power.

Pero algo que vimos todos los que presenciamos esta etapa de Intel surgió: no era mejor que un x86. En performance era... decepcionante y nadie quería portar sus aplicaciones, que ya funcionaban perfectamente rápido y optimziadas en x86, a una nueva y costosa arquitectura.

Cada CPU costaba unos USD 2000 para los modeos menores, DEC y SGI cayeron en desuso así que no fueron determinantes, Sun retrocedió y decidió continuar con Sparc, para 2001 nadie en el mercado se animaba a usar Itaniums en cantidad, si lo ofrecían era para ver qué decidía el mercado, pero sin mucho soporte.

Como siempre sucede en  los casos de una nueva arquitectura, la clave está en los costos y los compiladores, éstos no producían un buen código, faltaba trabajo y eso no atraía a developers corporativos donde el costo por watt era crucial.

Y luego llegó el golpe, como les comenté antes, AMD se puso manos a la obra en extender la arquitectura x86 para agregarle soporte de 64 bits y lo hizo. De un día para otro arrasó con los Opteron y los Athlon.

No existía mucho software que pudiera beneficiarse de los 64 bits todavía, pero, como todo developer sabía, era cuestión de tiempo ya que portarlo era trivial, así que el soporte era inmediato, ya cualquier aplicación de 32 bits funcionaba sin cambio alguno.

AMD pasó de ser inexistente en servidores a tener un 20% del mercado, Intel tuvo que aceptar la derrota y comenzar su propio desarrollo de la extensión de 64 bits, que no era complicada, simplemente la habían descartado en su sueño privativo del Itanium.

Para 2012 fusionaba las líneas de Xeon e Itanium, en enero de 2020 se anunció el retiro completo del mercado, no es que no funcionó completamente, pero la derrota fue total ante su propia invención, el x86 y la vergüenza fue el impacto de que su propio rival "menor" le impusiera la arquitectura AMD64.


En el camino Intel pasó por muchas pruebas difíciles, XScale es un ejemplo, en el momento que tuvieron procesadores RISC basados en diseños ARM decidieron venderlos, podrían haber entrado en el mercado de móviles desde un incio peleando con Qualcomm y hoy no estarían mirando desde afuera cómo la arquitectura "menor" los está apartando de una gran cuota de mercado.

La "lucha" entre CISC y RISC volvió de forma inesperada, pero esa es ya otra historia, Intel aprendió de sus errores y fracasos y no por nada están donde están ahora. El x86, por alguna extraña razón, sigue más vivo que nunca.

Si te gustó esta nota podés...
Invitame un café en cafecito.app


Otros posts que podrían llegar a gustarte...

Comentarios

  • CoYo     03/04/2024 - 12:52:45

    La historia "tech" es apasionante. Lamentablemente es compleja de entender y explicar.
    Hablar de arquitecturas de procesadores suele ser muy difícil de explicar, y quizás, la mejor forma de describir las diferencias es que, básicamente, todas hacen lo mismo pero de formas mas o menos eficientes.
    Hoy, en la práctica, se puede explicar en el uso de CPUs vs GPUs para las mismas tareas y la diferencia de rendimiento de cada una en tareas específicas.
    Otra conclusión a la que se llega es que, sin duda, siempre prevalecen las arquitecturas mas flexibles.
    Intel demostró que se aprende de los errores (y vaya si cometió muchos) y AMD demostró que, siendo flexibles y adaptándose a las verdaderas necesidades (de bajar costos sobre todo) pudo, en su momento, destronar a Intel.
    Cuando salieron los 386 y 486 de AMD fueron, a mi criterio, un momento épico (donde con la mitad del presupuesto tenías, incluso, mejores prestaciones versus Intel)
    Lo bueno de todo esto es que, en definitiva, en estas batallas, siempre terminamos ganando todos.
    Y, los que hemos tenido la suerte de poder vivir todo este desarrollo (como en mi caso, que viví desde la CZ1000 hasta la actualidad), no paro de sorprenderme lo que se ha avanzado en tan poco tiempo.
    Muy buen post. Y sí, tenemos x86 para rato (aunque ya va siendo hora de salir de los límites que impone)

  • gorlok     04/04/2024 - 10:37:27

    De todas formas los x86 tampoco ya son CISC per-se, son híbridos. Es una API que internamente se traduce a microcódigo similar al RISC. Pero toda esa complejidad extra tiene su costo. El RISC de ARM y otros es más directo y simple, y por ende más eficiente.

  • jpvalverde85     04/04/2024 - 11:17:15

    gorlok dijo:

    De todas formas los x86 tampoco ya son CISC per-se, son híbridos. Es una API que internamente se traduce a microcódigo similar al RISC. Pero toda esa complejidad extra tiene su costo. El RISC de ARM y otros es más directo y simple, y por ende más eficiente.

    ES LA GRIETA!
    https://hackaday.com/2024/03/21/why-x86-needs-to-die/
    https://chipsandcheese.com/2024/03/27/why-x86-doesnt-need-to-die/

    Hoy si bien tiene algunas dificultades y limitaciones la traduccion a microcodigo, se ha estado trabajando en alivianarlo a costas de compatibilidad legada, pero no es poco ni para descartar todo el software que ya funciona y bien en x86 y x86-64, ARM tambien ha tenido que ir dejando compatibilidad legada en el camino, y el ecosistema de ARM esta bastante mas fraccionado en cuanto a hacer andar todo el sistema (no solo el procesador). Para mi el que esta creciendo a tranco largo es RISC-V porque tiene un espectro muy amplio de aplicación y porque al ser una definición libre el mismo volumen de uso por practicidad va a hacer un efecto bola de nieve en la adopción de la arquitectura, espero que sepan llevar la definición con orden y criterio, y que no se abandone al mejor postor.

  • Santiago     05/04/2024 - 08:48:29

    Faltó mencionar la última evolución de x86, en la que Intel propone eliminar el soporte de SO de 16 y 32 bits. La idea es que el procesador arranque directamente en modo de 64 bits, y soportaría software de usuario de 32 y 64 bits. De esta forma podrían simplificar la arquitectura eliminando todo el bagaje histórico.

    https://en.wikipedia.org/wiki/X86-64#X86S

    • Fabio Baccaglioni     05/04/2024 - 12:51:45

      No faltó, está al comienzo del artículo:


      Recién ahora, en 2024, muchas de esas capas "legacy" quedarán obsoletas y lo antiguo dependerá de la virtualización, pero luego de tantos años era hora.


      pero como eso no es "matar" al x86 sino "limpiarlo", no es tan relevante al artículo

Deje su comentario:

Tranquilo, su email nunca será revelado.
La gente de bien tiene URL, no se olvide del http/https

Negrita Cursiva Imagen Enlace


Comentarios ofensivos o que no hagan al enriquecimiento del post serán borrados/editados por el administrador. Los comentarios son filtrados por ReCaptcha V3.