El 386 (1986)

El 386 fue un éxito de ventas incluso antes de que apareciera el software que exprimiera todo su potencial. ¿Era sólo hype o realmente supuso un cambio revolucionario? Curiosamente, IBM no fue el primero en participar en la generación de 32 bits del PC que él mismo había inventado, sino que Compaq y Zenith tomaron la delantera.

[#101 Azrapse]

#87 Seguramente se refería a la arquitectura superescalar con multiples pipelines.
Es decir, en lugar de ejecutar una instrucción a la vez, como los anteriores procesadores hacían, el Pentium podía ejecutar múltiples instrucciones a la vez en paralelo. Antes de eso, era habitual hablar de "ciclos por instrucción" para referirse a la velocidad de una CPU. Pero a partir del Pentium, se pasó a hablar de "instrucciones por ciclo", puesto que en un mismo ciclo de reloj, la CPU podía ejecutar multiples instrucciones.
Recordemos, todo esto con un solo "core".

[#102 --763016--]

#101 nunca entendí eso de ejecutar instrucciones en paralelo ¿y si para ejecutar una instrucción necesitas saber el resultado de la anterior?

[#103 Azrapse]

#101 Más información: en.wikipedia.org/wiki/Pentium_(original)#:~:text=Superscalar architect.

[#104 lectordigital]

La verdadera revolucion era para los programadores en ensamblador ya que el direccioamiento de memoria no iba segmentado como en el 8086 y 80286. Por motivos de compatibilidad estos procesadores iniciaban con el modo antiguo de direccionamiento de los 8086 y por software luego podias pasar al modo 32bits.

[#105 nexus5]

#98 Lo mismo que yo, jejeje

[#106 Azrapse]

#102 Es lo que menciona el compañero con reordenado de instrucciones.
Si el procesador detecta que cierta instrucción B necesita el resultado de la anterior instrucción A, entonces lo que hace es meter instrucciones posteriores o anteriores C, D, E, que no necesitan de ese resultado y las ejecuta antes que B. Por ejemplo, si el programa originalmente era
A
B (depende de A)
C (no depende de A ni B)
D (no depende de A ni B)
E (no depende de A ni B)

el procesador las reordena "al vuelo" en algo como A, C, D, E, B.
Básicamente, mientras que espera a que termine A, adelanta trabajo que tiene que hacer después, y luego sigue con B, y ese trabajo que ha adelantado ya no tiene que hacerlo.

[#107 Azrapse]

#106 Por supuesto, siempre se puede dar el caso que el procesador no pueda encontrar ninguna otra instrucción que pueda meter en los tiempos de espera entre instrucciones que dependen una de la otra. En esos casos, mete una instucción NOP (no operation, no hacer nada).
Pero la inmensísima mayoría de programas y rutinas son suficientemente largos en código máquina como para que haya instrucciones de sobra para rellenar huecos.

[#108 --763016--]

#106 También tendrá que saber que instrucción va a acabar antes que otra, Eso puede ser un follón , además el programador ya no puede estar seguro de en qué orden se van a ejecutar las cosas y luego aparecen bugs que nadie entiende si revisas el código fuente en un lenguaje de alto nivel.

[#109 bitman]

#2 8086/8088
Un equipo con un 386 ya era un señor ordenador

[#110 bitman]

#60 8086 y 8088 salieron prácticamente a la vez (el 8088 solo difería en pequeños detalles que lo hacían más económico). Después salieron los 80186/80188, los 286, 386, etc

[#111 bitman]

#69 el 386 le daba mil vueltas al 286

[#112 Azrapse]

#108 Si no recuerdo mal, todas las instrucciones tardan lo mismo. Las instrucciones de la familia CISC x86 se traducen a instrucciones más sencillas RISC dentro de la CPU, que todas duran lo mismo. O al menos todas tienen la misma cantidad de etapas. En cierto modo, se puede ver al Pentium y posteriores como procesadores RISC que ejecutan instrucciones CISC a base de traducción en tiempo real.
El código CISC del programa se traducen en microcódigo RISC que es lo que realmente se ejecuta.

El programador tiene la certeza de que, haga lo que haga la CPU, el resultado del programa es idéntico, porque se garantiza la coherencia del mismo. Cuando se reordenan instrucciones, como las instrucciones que cambian de posición no usan resultados de las anteriores, el cálculo final es el mismo.
En situaciones donde el programador pudiera confundirse, como por ejemplo, al ejecutar un depurador paso por paso, toda esta reordenación y tal es desactivada.

[#113 tremolantepenacho]

#2 Si no recuerdo mal, el XT llevaba un 8088 y el AT un 8086

[#114 tremolantepenacho]

#92 Yo también me compré un 486 DX33 en el 95 y me costó (a mi padre) 200.000 pesetas.

[#115 bitman]

#17 qué cosa tan bonita

[#116 bitman]

#23 esas matriciales tirando folios a las 2 de la madrugada porque no llegabas para entregar el trabajo! Qué recuerdos!!

[#117 --763016--]

#112 Sí, supongo que todo esto estará más que estudiado y tanto las CPUs como los compiladores deben tener todo esto en cuenta.
De lo que si las CPUs tardan lo mismo en ejecutar cada instrucción pues no lo sé, pero en procesadores como el z80 no, cada instrucción utilizaba distinto número de ciclos de cpu, incluso recuerdo que ciertas instrucciones requerían una barbaridad de ciclos y se procuraba no usarlas nunca.

[#118 nacho_lobez]

#96 Cierto, el XT era el 286 y el AT el 8088.

[#119 Azrapse]

#117 Efectivamente. En la arquitectura CISC, podías tener una instrucción de suma que tardaba un ciclo, y una instrucción de búsqueda de un valor en un array, que podía tardar, buf... 1000 ciclos o más?
En RISC, todas las instrucciones duran exactamente lo mismo porque son sencillísimas: obtener instrucción, obtener valor que opera, hacer operación (suma, resta, comparación, cosas muy simples), almacenar el resultado.
La instrucción CISC de búsqueda de un valor en un array se traduciría por tropecientas instrucciones RISC.
El quid es que ejecutar instrucciones RISC nos permite hacer todos estos trucos de reordenar instrucciones, tener multiple pipelines, etc, con lo que merece la pena el esfuerzo de diseñar todo eso.
Y, en fin, el tiempo les dio la razón.

[#120 Brigo]

#114 Yo también me compré uno así por esa época, pero del 92 al 95 los precios bajaron enormemente. Recuerdo que tengo un amigo con familia en los USA y le trajeron uno de allí en el 92, y aún así fue caro.

[#121 Edheo]

#111 si.... y más tarde le metí el copro, y bueno, una maravilla

[#122 Goomer]

#99 El PC1512 normalmente llevaba el 8086 pero El Corte Ingles sacó una versión "barata" que montaba el 8088, tarjeta CGA y monitor B/N, el mío tenía dos floppys 5 1/4.

[#123 anv]

#32 A nosotros el profesor de Técnicas Digitales nos decía que un 386 en un PC era como querer tomar agua de la manguera del bombero. Totalmente inútil y desproporcionado. Nadie necesitaba tanto.

Se podría juntar con Bill Gates que dijo que nadie iba a necesitar más de 640Kb de RAM.

[#124 herlocksholmes]

#72 Un respeto, yo usaba ordenadores cuando el espermatozoide de su padre estaba en un testículo de su abuelo

[#125 fingulod]

#85 El 386SX salió bastante después que el 386 "a secas", cuando los 386 eran caros, pero no prohibitivos. O eso me parece recordar.

#93 ¿Se llamaba o la llamaban Baby AT para diferenciarla de la ATX? Me suena algo así

#112 No sé si el Pentium ya hacía esto, o fue algo posterior. Otra cosa es que como dice #117 sepas el número de ciclos que va a tardar una operación.

[#126 --763016--]

#93 El PC original (IBM 5150) , usaba un 8088 pero no era XT, Los modelos XT (eXtended technology) salieron después, aunque también usaran el 8088.

[#127 Khadgar]

#124 Estaría en un testículo de su padre.

[#128 meneandro]

#30 El copro hacía operaciones en coma flotante muy precisas, pero también de manera muy lenta (para los estándares actuales ya ni te cuento). No tanto las operaciones en si (si no hubieran sido rápidas, no tendría sentido) sino la comunicación con el procesador (el procesador se quedaba "bloqueado" a la espera, cedía el control de ejcución al coprocesador por así decirlo y luego lo recuperaba). Esto, como comprenderás, es un lastre muy grande para un juego que quiere mover muchísimas cosas por pantalla muchas veces por segundo.

"nother point not addressed in the existing answers relates to the latency associated with accessing an external coprocessor.

The first math coprocessors, while much faster than doing the same work on a CPU, still took many clock cycles to complete each operation. The overhead (bus cycles) associated with transferring data between the two chips was "lost in the noise". In other words, there was no penalty for putting those functions in a separate chip.

However, as coprocessors got faster, this overhead became a significant bottleneck on throughput, and this is what drove integrating them directly into the CPU chip."

[#129 meneandro]

#97 Precalcular siempre es más rápido porque una vez hechos los cálculos, nunca vas a tener que repetirlos (se guardan en disco o memoria y ya está). Y eso no implica hacerlo siempre o la primera vez que ejecutas el juego, lo haces "de fábrica". De hecho, algunos aspectos de todos los niveles son "precalculados" (las luces y sombras de los escenarios de juegos de la época se generan, se dibujan y se guardan, son estáticas, se cargan con el nivel y se añaden como una capa de dibujado más). De hecho, en el quake original y muchos otros juegos, los niveles se compilaban. Eso de lenguajes de scripting dinámicos donde las cosas de un juego se evalúan sobre la marcha llegaría más tarde (a partir del unreal, probablemente el quake 2 o poco antes).

[#130 ViejoInsultaAChemTrail]

#122 no la conocía

[#131 eljuligallego]

#123 cuanto cuñado hay en las facultades artísticas.

en el FP de sonido con el tema de los Macs era todo humo y un montón de hype

[#132 diablos_maiq]

#113 el AT un 286, de eso sí me acuerdo

[#133 lectordigital]

#110 El 80186 estaba mas dirigido a microcontrolador

[#134 lectordigital]

#118 al reves xt 8086 y at 80286

[#135 lectordigital]

#122 El PC1512 y el PC1640 de Amstrad esos se vendian y regalaban como churros !!

[#136 tremolantepenacho]

#120 Sí, cuando me lo compré ya habían salido los DX2 así que los DX bajaron de precio y los DX desaparecieron.

[#137 herlocksholmes]

#127 Ambos "su" se refieren a usted, caballero. Que yo hablo como cuando era joven, en la época victoriana

[#138 pcmaster]

#65 El coprocesador era el 8087

[#139 Frank39]

Mi primera máquina fue en el 92, 386 sx a 33 MHz.

[#140 c0re]

#118 no, el AT fue 286 también

es.m.wikipedia.org/wiki/IBM_Personal_Computer/AT

[#141 Jesusor]

#90 No. Estaba hecho para MS- DOS . No necesitaba ningún emulador.
El programa no era lento. Sí lo era para renderizar, claro.

[#142 Acido]

#65
No. El coprocesador más popular de aquella época era el 8087.
Aunque según he leído ahora también hubo otro llamado 8089.

#75 ¿Cómo que cierto?

#60 ¿Cómo que "incorrecto"?
No es incorrecto que después del XT saliera el AT... son modelos de PC de marca IBC.

Una cosa es el PC (ordenador, con su placa madre, su memoria, su fuente de alimentación... ) y otra cosa es el microprocesador, un chip, una piececita del ordenador... la más representativa / importante, pero solo una pieza.

#4 A mi también me sonaba el 386 bastante posterior a esa fecha... Pero antes la fecha de salida de un chip era muy anterior a los primeros ordenadores con ese chip. Intel sacaba un chip al mercado, normalmente caro ya que era una innovación, una novedad. Los fabricantes se ponían a diseñar el ordenador con ese chip, según las especificaciones y a veces también tardaba en adaptarse algún sistema operativo a ese chip.

Según he leído ahora, el 8086 salió en 1978 y el 8088 en 1979 pero el AT (PC de IBM con 8086) salió en 1984, coincidiendo cuando Apple hizo su anuncio (¿final de 1983? ¿1984?) aludiendo a la novela de Orwell, "1984". Los Apple llevaban otro chip, de Motorola, por eso no eran compatibles.
Pero vamos, que pasaron 5 años desde el chip hasta el PC con ese chip. Y el primer AT costaba un dineral, más de 1500 dólares, equivalentes a unos 4500 euros de 2021. A lo mejor los PC asequibles compatibles x86 (clónicos, etc) salieron hacia 1988, ¡unos 10 años después que el chip 8086! El primer PC de mi casa fue con chip 8088, por esa época, 1988 ó 1989.

El 386 es de finales de 1985 y quizá fue asequible en 1993... por eso nos suena posterior, 6 ó 7 años después de salir a la venta el chip, porque no comprábamos chips sino PCs asequibles.

Ahora la industria se ha acelerado y cuando sale un chip solo tardan a lo mejor 3 meses en sacar aparatos con ese nuevo chip.

[#143 Khadgar]

#137 Comprendido, que tenga un buen día.

[#144 Conde_Lito]

#35 El Win95 yo lo llegué a instalar varias veces en un 386SX 25Mhz con 4Mb de RAM, un disco duro de 80Mb y una gráfica Trident TVGA 8900 con 1Mb VRAM que supuestamente llegaba a los 65.536 colores, yo al menos no pude sacar de esa gráfica más de 256 colores con una resolución de 640x480..., probablemente fuera por los drivers que no tenía y como pese a todo lo que se vendió esta gráfica tampoco venían con el Windows 95...
Luego añade que la versión del Win95 era la OSR2, que ya venía con el iExplore, soporte para USB, AGP, FAT32 y demás, y lo mejor de todo era que el ordenador no tenía CD-ROM , con 15-16 años, a mediados de los 90, no me podía gastar casi 20.000 Ptas. en un CDROM.
Así que adivina como instalé el Win95..., 26 maravillosos disketes de 1.68Kb que me dejaron copiar en el instituto. 3 horitas y algo duraba de media la instalación.
La secuencia de la disquetera durante la instalación era maravillosa, se encendía el LED verde, leia un par de pistas, si había suerte quizá leía una tercera pista, "clac - clac", se apagaba el LED, entre 8 y 10 segundos de silencio mientras el ordenador descomprimía y almacenaba en la memoria las dos pistas que acababa de leer, se vuelve a encender el LED, lee otras dos pistas, "clac - clac", se apaga el LED, otros 8-10 segundos de silencio y así con los 26 disketes...
Cabe señalar que el programa de instalación no descomprimía los .CAB directamente en el disco duro sino en la memoria RAM, una vez llena ya sí volcaba todos los archivos descomprimidos al disco duro, con 4Mb de RAM esta operación la hacía cada 2-3 disketes, tardaba algo menos de 1 minuto en volcar al disco todo lo que había descomprimido en la memoria.

Peores chapuzas y menos funcionales hice un tiempo antes, con un 286 y un Windows 3.11 que no me dejaba instalar el MS Word 6.0
El sistema operativo no era el problema, el Word 6.0 si no recuerdo mal se podía instalar sin problema en un Win 3.x o un NT 4.5x, funcionaba sin problemas con sistemas operativos de 16 bits, el problema era el procesador del ordenador, el 286.
El 286 no está programado/diseñado a nivel interno, a nivel electrónico, para trabajar con una memoria virtual como ya si lo estaba el 386 y sucesivos, por lo que si se acaba la memoria física, si uno o varios programas te comen toda la memoria RAM, el procesador no puede utilizar el disco duro como si fuera memoria RAM y el ordenador o bien acaba por bloquearse o bien va tan lento que acabas apagándolo a la brava porque es imposible hacer nada.
La instalación del Word 6.0 ya me dio pistas de que no iba a ir nada bien el tema, se tiró casi 1 horita de nada para escupir el mensaje de error diciendo que no tenía memoria virtual suficiente para continuar con la instalación...
En resumidas cuentas, lo que hice fue descomprimir en un directorio del disco duro todos los archivos de los 10 disketes del Word.
Me tiré hora y algo descomprimiendo pero "mereció la pena", sí entre comillas , el Word se ejecutó sin problema, tardó así como 5 minutos en abrirse pero lo hizo, ahora bien, era del todo inutilizable ya que la memoria del ordenador estaba hasta arriba y cada dos por tres el word accedía al disco duro para leer otra vez el programa, el word y sus librerías, se tiraba varios minutos leyendo incluso cada vez que parpadeaba el cursor, y como este no para de parpadear tampoco paraba de leer el disco...
Para escribir una sola letra te podías tirar varios siglos.

[#145 sesshoumaru]

#67 El pentium es in-order, aunque si que tenía dos unidades de ejecución, U y V, no simétricas. El primer x86 de Intel OoO (fuera de orden) fue el Pentium Pro (P6), aunque Nexgen/AMD ya se le habían adelantado.

El 386 mejoró muchas cosas de x86: introdujo la paginación, hizo mucho más ortogonal el juego de instrucciones,...

[#146 WifredoIII_ElGayu]

Yo realmente sigo esperando una revolución similar en la informática. Quizás ni siquiera tenga que ser de hardware, a lo mejor basta que sea de software, pero algo que nos lleve a otra fase informática.

Quizás lo más parecido a algo así podría haber sido la gama M de Apple, pero viendo que llevan dos años, y todavía la competencia ni siquiera les haya intentado ni copiar/seguir, me dice que M no es para tanto

Mi otra esperanza es Nvidia/similares, donde el potencial de sus procesadores puedan pegar un empujón al mundo informático base, y no solo al minado y a los LLMs

[#147 sesshoumaru]

#102 En realidad el Pentium podía ejecutar en paralelo sólo algunas cosas.

En el caso del P6 (Pentium Pro, Pentium II, ...), hay una primera parte del procesador (frontend) que funciona en orden, al final de esta parte se asignan los registros de la instrucción a registros reales del procesador (que son muchos más), guardándose esta asociación en la RAT (Register Alias Table) (los registros que se usen como fuente se buscan en los que ya están en la RAT, los usados como destino se asocian a uno libre) y se guarda información sobre la instrucción en algo llamado Reorder Buffer (ROB). El ROB va enviando instrucciones que estén listas para ejecutarse (los registros de los que dependen ya tienen su valor válido) a unidades de ejecución que estén disponibles. Según las unidades de ejecución terminan de ejecutar las instrucciones, estas últimas se van retirando del ROB en orden.

[#148 sesshoumaru]

#108 Eso es porque intuitivamente esperas que varios hilos de ejecución se comporten como si se entrelazaran sin alterar su orden (modelo de consistencia de memoria Sequentially Consistent), y esto no siempre es así.

Hay que conocer el modelo de (consistencia de) memoria del lenguaje, que típicamente se basa en relaciones de orden como happens-before, synchronizes-with,... para que las cosas cobren sentido.

[#149 ViejoInsultaAChemTrail]

#144 ole tu, el mio era de 40mhz tenia menos mértio. La vga no recuerdo pero creo que era una trident vga. Lo tendría que mirar. Da gusto conocer a gente asi. De todos modos lo mio ya fué un experimento tardío, lo del win95, ya tenía el pII. Toda su vida útil fue con msdos 6.2x. Y el mítico xmms y emms en el autoexec.bat a parte de los programas con modo protegido como doom. No recuerdo si los cab los descompirmí yo... aunque ahora que lo dices igual... pero son tantas batallitas y experimentos en 44 años, que no sabría decirte... además allá por el 96 tuve la suerte, con 16 años, en hacer un curso de programación donde descubrí slackware 3 y a partir de ahí, si no es por los juegos, fuí pisando cada vez menos terreno windows. Es verdad que aun el pc potente de la casa lo tengo con win10, por lo de siempre. Juegos. Y me da pereza meterme con wines y steams. Soy un early adopter del wine y quizás por eso me cansé. Mis experimentos a dia de hoy son mas de sistemas, redes, lfs, wasm etc...
Así acabé programando sistemas embedidos -era pre android/ios, pues ya arm existía... jtags...uclinux sin gestor de memoria- hasta que la vida me llevo a la tranquilidad del devops, la nube y esas movidas... que dan de comer, amplian el horizonte pero ni son tan complejos ni motivan tanto. Igual también es que uno se hace mayor. En fin.

Gracias x tu repsuesta

[#150 sesshoumaru]

#112 No todas las instrucciones tardan lo mismo. Como ejemplo trivial, acceder a memoria, si no está en caché, puede tardar fácilmente un par de cientos de ciclos.

El Pentium no es internamente RISC. Su capacidad de ejecutar en paralelo se limita a determinados pares de instrucciones, en el caso de que las dos instrucciones no estén en conflicto.

[#151 Conde_Lito]

#23 Según la publicidad que tengo de la época, cuando salió a la venta en 1981 el IBM PC (5150) la configuración más básica costaba la friolera de un millón y medio de Ptas., procesador 8088 a 4.77Mhz, 64Kb de RAM ampliables a 256Kb, tarjeta gráfica MDA, monitor de fósforo verde, 2 disketeras de 5^1/4 de 160Kb cada una, Bus ISA de 8 bits y sin disco duro
Con monitor en color y tarjeta gráfica CGA se te ponía en los 2 Millones de Ptas.

Cuando salió en 1983 el IBM XT (5160) se puso prácticamente al mismo precio que el IBM PC aunque bajó rápido.
El IBM PC bajó bastánte de precio, llegando a costar sobre el millón de Ptas la versión con gráficos en color.
El XT ya venía de serie con un disco duro de 20Mb en su configuración más baja, procesador 8086, 128Kb de RAM, Bus ISA de 16 bits, monitor de fósforo verde o naranja y gráfica MDA.

En el año 85-86 te podías comprar de segunda mano un 5150 con gráficos en color por medio millón de Ptas. más o menos, y sobre las 200.000 - 300.000 el de fósforo verde, del XT no tengo referencias.
Los clónicos nuevos no bajaban de las 350.000 Ptas. con monitor monocromo y en color se podía ir la cosa a más de 500.000 Ptas.
Y ya si nos vamos a los IBM AT o los clónicos que montaban un 80286, estos últimos no bajaban de las 750.000 Ptas a mediados de los 80..., Y los AT no bajaban del millón y pico en su configuración más básica.
En muy poco tiempo también bajaron de precio estos últimos de precio ya que no tardó en salir al mercado el 80386 dejando en muy poco tiempo totalmente obsoletos los ordenador que montaban procesadores anteriores a este.

[#152 sesshoumaru]

#117 Bueno, lo de que está todo estudiado tiene sus contraejemplos.

Por ejemplo, como saber si la condición de un salto condicional va a ser verdadera puede llevar su tiempo (especialmente si se fuerza a que dependa de algo que no esta en caché), los procesadores pueden seguir ejecutando especulativamente montones de instrucciones, y si la condición resulta ser diferente a lo que se esperaba, hay que revertir todo (¿seguro?) el estado cambiado por esas instrucciones.

Pero alguien con muy mala idea puede haber decidido usar la caché como un canal de comunicación oculto, y puede que pueda inferir el valor de cosas a las que no debería poder acceder según lo que tarde en acceder a un valor dummy, que estará o no en caché según ese código que en realidad no debería haberse ejecutado, y no debería haber cambiado ningún estado.

Para más información, buscar Spectre, Meltdown, y sus muchas variantes.

[#153 rafaLin]

#141 Me refiero al emulador de coprocesador. Si eras pobre y no tenías copro, al ejecutar el Autocad (y supongo que el 3d studio) no se abría, daba error y decía que te compraras uno. Pero había un emulador de copro por software que las instrucciones matemáticas del Autocad se las pasaba al procesador normal, iba lentísimo pero funcionaba.

Vamos, que cada vez que autocad quería hacer una multiplicación, el emulador la transformaba en varias sumas y las mandaba al procesador. Todo sin que el Autocad se de cuenta, él piensa que está usando el copro.

[#154 rafaLin]

#153 Para Autocad 2d el emulador era lento pero usable, para renderizar 3D tenías que tener una paciencia infinita, una cosa que el copro te renderizaba en una hora, con el emulador tardaría días o semanas.

[#155 pcmaster]

#63 En un 386 posiblemente sería una Realtek, ATI, Trident, Cirrus Logic , Tseng labs o Diamond. Pero S3 Virge no, esa era PCI.

[#156 Jesusor]

#153 Ah, vale. Entiendo.

[#157 SpeakerBR]

#108 Evidentemente era un follón, pero vamos, después de lo de la memoria segmentada del 8086 (algo como el problema de los punteros de C, pero a lo bestia) todo lo demás era trivial.

Todo esto era para que se ocuparan los compiladores de optimizar el código. Cuando generabas el código podías elegir si sacarlo optimizado por tamaño, por velocidad, por plataforma (386, pentium,...)

No deberían aparecer bugs y si aparecieran, no es problema del código sino del compilador. Pero no recuerdo ningún problema al respecto. Si que recuerdo que un famoso compilador de intel generaba el código más rápido para chips Intel que para chips AMD...

[#158 kampanita]

#114 A mi lo mismo, 200.000

[#159 ferrisbueller]

#54 Tieso! en el 92 ya existia el 486 (digo con envidia porque en el '92 yo tenia un Z80 )

[#160 calaverax]

#123 leí por ahí que Bill Gates nunca dijo eso, pero no decían de quién era la frase.