Sophie Wilson: ARM y cómo simplificar las cosas las hizo más rápidas y efectivas

Sophie Wilson es una de las principales luces del diseño de CPU moderno. En la década de 1980, ella y su colega Steve Furber diseñaron la arquitectura ARM, un nuevo enfoque para el diseño de CPU que permitía la informática móvil. Lo hicieron al darse cuenta de que puede hacer más y más rápido con menos. Si está utilizando Raspberry Pi, o algunos de los innumerables dispositivos integrados que se ejecutan en chips ARM, ha disfrutado de los frutos de su trabajo.

Todo comenzó para Sophie Wilson con un encendedor eléctrico y una máquina tragamonedas (o máquina de frutas, como se les llama en el Reino Unido) en 1978. Un aspirante a ladrón descubrió que si encendía un encendedor eléctrico al lado de la máquina, la banda ancha electromagnética resultante el pulso podría activar el circuito de recompensa. Al diseñador electrónico Hermann Hauser se le asignó la tarea de resolver el problema y se dirigió a Wilson, un estudiante que trabajaba en su empresa.

Wilson asumió rápidamente que si agregaba un pequeño receptor de radio de banda ancha para detectar el pulso, podría suprimir el pago falso, evitando al ladrón. Impresionado por esta innovación, Hauser desafió a Wilson a construir una computadora durante las vacaciones de verano, en parte en un proyecto para un comedero automático de vacas que Wilson creó en una universidad. Wilson creó este prototipo de computadora, que parecía más una calculadora con cable que una computadora moderna, pero el diseño se convirtió en la base del Acorn System 1, la primera computadora que lanzaron las nuevas computadoras Hauser Acorn en 1979.

Wilson se graduó de la Universidad de Cambridge en ese momento y se unió a Acorn como diseñador principal. El System One era inusual en el sentido de que era económico: con un precio de £ 65 (menos de $ 90), la computadora se vendió como un kit que el usuario podría armar y lutus ellos mismos. Fue construido alrededor de una CPU 6502 de 1 MHz, con 1152 bytes de RAM.

En los años siguientes se lanzaron varias versiones nuevas de esta computadora, agregando características como tarjetas de expansión. Estos fueron populares entre los entusiastas, pero nadie capturó la imaginación del público de la forma que esperaba la compañía.

Computadora en todas las escuelas

Hermann Hauser, Andy Hopper, Christopher Curry, Sophie Wilson, David Allen, Chris Serle, David Kitson, Chris Turner, Steve Furber en el 30 aniversario de BBC Micro en 2012. De Wikipedia.

La gran oportunidad de Acorn llegó con BBC Micro, una computadora que fue diseñada para acompañar a un programa de lectura de computadora dirigido por la emisora ​​británica. BBC Micro fue diseñado para ser lo suficientemente robusto para uso educativo, con un teclado de tamaño completo, un intérprete BÁSICO, un módulo que le permitía conectarse a un televisor estándar y una interfaz para almacenar y recuperar programas en una grabadora de casete estándar. . Tuvo mucho éxito, vendiendo más de 40.000 máquinas al mes y apareciendo en el 85 por ciento de las escuelas británicas.

Pero luego los pensamientos de Wilson cambiaron a otra parte. BBC Micro usó el mismo procesador 6502 que sus computadoras anteriores, pero Wilson y otros en la compañía no estaban contentos con la cantidad de potencia de la computadora que esto proporcionaba. Entonces decidieron en 1983 construir su propia CPU para computadoras futuras.

Varios factores influyeron en esta decisión. Una fue una visita a la empresa que fabricó el 6502, donde notaron que una persona estaba trabajando en la próxima versión de esta CPU. Esto demostró que no se necesitaba un gran equipo para diseñar una CPU: siempre que tuviera un socio que pudiera crear el chip por usted, no era tan difícil. El segundo fue un proyecto llamado proyecto Berkeley RISC, que significaba códigos de instrucción reducidos. La idea detrás de esto era que si se creaba una CPU para ejecutar solo un conjunto muy pequeño de instrucciones, podría ejecutarse más rápido y de manera más eficiente. En lugar de agregar más instrucciones al procesador en sí, el sistema operativo que se ejecuta en la parte superior del procesador dividiría las tareas en instrucciones más simples para que la CPU se ejecutara más rápido.

A Wilson le gustó esta idea. Entonces, ella y su colega Steve Furber diseñaron su propio conjunto de instrucciones, creando un simulador en BBC Micro que convenció a otros en la compañía de que el enfoque valía la pena. Llamaron a este Proyecto A, pero luego fue bautizado como el Máquina RISC Bellota o BRAKO.

Más pequeño, más rápido y mejor

La arquitectura de su sistema es fundamentalmente diferente de la mayoría de las CPU. Wilson y otros probaron el 6502 y otros procesadores similares y descubrieron que solo pueden procesar una cantidad limitada de datos. La mayoría de los diseñadores de CPU han agregado más instrucciones a sus chips, proporcionando nuevas formas para que la CPU procese y procese estos datos. Wilson y Furber tomaron el enfoque opuesto, eliminando partes hasta que tuvieran lo básico necesario, creando un poco más simple y requiriendo menos energía que las CPU existentes. Esto significaba que era mucho más fácil manejar la CPU con números más grandes. Debido a que la arquitectura era más simple, era más fácil crear CPU de 16 o 32 bits. Al crear menos, Wilson y Furber produjeron un chip que podía hacer más.

Tomemos un ejemplo, uno que usa el propio Wilson. La CPU 6502 que usó en BBC Micro necesitaría 2 ciclos de reloj, o aproximadamente 1 microsegundo para sumar dos números de 8 bits. Pero cuando comienza a usar los números más grandes requeridos por la mayoría de las tareas de la computadora, el 6502 evita que tengan que lidiar con estos números en bits de 8 bits. Esto se debe a que el 6502 solo funciona con 8 bits de datos a la vez (llamados buses de datos amplios), por lo que necesita cortar números más grandes en bits de 8 bits y agregar estos bits uno a la vez, lo que lleva tiempo. De hecho, el 6502 necesitaría 26 ciclos de reloj para unir dos números de 32 bits.

Podría construir una versión del 6502 que tuviera un bus de datos más grande, pero eso aumentaría exponencialmente la cantidad de transistores que requería el chip: rápidamente necesita millones de transistores para manejar las operaciones complejas en estos bloques de datos más grandes. Alternativamente, podría hacer lo que hizo Steve Wozniak con Sweet16, un truco que escribió para Apple II (que usaba el mismo procesador 6502 que BBC Micro), que creó efectivamente un procesador virtual de 16 bits. El problema era que corría a una décima parte de la velocidad del 6502.

Por el contrario, la primera CPU ARM que Wilson y Furber construyeron tenía un ancho de bus de datos de 16 bits y funcionaba a una velocidad de reloj más rápida que la 6502, por lo que podía agregar dos números de 32 bits en nueve ciclos de reloj, o aproximadamente 125 nanosegundos. Y podría hacerlo con un chip no mucho más grande que el 6502. Podría hacerlo porque la arquitectura más simple se escalaba más fácilmente para trabajar con los buses de datos anchos más grandes. Debido a que solo tenía que procesar unas pocas instrucciones, el chip era más simple y rápido.

Wilson y Furber diseñaron una CPU, un chip gráfico y un controlador de memoria que trabajaron juntos para crear un sistema completo de prueba que se entregó en 1985. Cuando Furber decidió medir cuánta energía usaba ese procesador de prueba, su multímetro no pudo detectar el flujo de energía. Furber investigó y notó que la placa de desarrollo que usaban estaba defectuosa: no entregaba energía a la CPU. En cambio, el procesador estaba bastante felizmente alimentado por la energía entregada a través de las líneas de señal que alimentaban datos a la CPU.

Acorn se dio cuenta rápidamente del potencial de este diseño y pasó a patentar las técnicas que utilizaba. Esto creó la primera arquitectura RISC práctica, llamada ARM V1. Esto ha pasado por varias repeticiones desde entonces, pero lo básico sigue siendo el mismo: pocas instrucciones que funcionan rápidamente son más efectivas que muchas instrucciones que duran mucho tiempo.

Mientras Wilson creó las primeras CPU ARM, el propio Acorn tuvo problemas. El BBC Micro, aunque popular, era caro de producir y los problemas de producción hicieron que la empresa se perdiera la temporada de compras navideñas de 1983. Aunque se encargaron más de 300.000 BBC Micros, en Navidad de 1983 sólo se entregaron 30.000. significativamente para expandir la producción y desarrollar el próximo modelo, el BBC Master. Un acreedor se sintió frustrado y trató de cerrar la empresa, un proceso que causa despidos y problemas financieros que finalmente significan que Acorn fue vendida, pasando por las manos de algunas empresas diferentes y quitando la parte ARM de la empresa que rápidamente valía más. que la propia Bellota.

La arquitectura ARM en sí tardó algún tiempo en popularizarse, pero el principal impulsor de esto fue la informática móvil. Dado que la potencia supera a la movilidad, la arquitectura ARM es ideal porque puede alimentar más operaciones con menos potencia que los chips más complejos. De hecho, la arquitectura ARM todavía se usa en la mayoría de los teléfonos móviles, computadoras portátiles y otros dispositivos, y empresas como Apple, Samsung y muchas otras autorizan el uso de la arquitectura ARM en sus procesadores móviles.

  • David Cramer dice:

    Por desgracia ... La falta de reconocimiento histórico por parte de Bill Mensch y The Western Design Center (que todavía comercian entre sí) es solo una injusticia para el trabajo. Desafortunadamente, esta pequeña referencia ha influido mucho en el éxito de la Sra. Wilson.

    • Jonathan dice:

      Ese no es el único "abandono" o "inexactitud".

      ¿Quizás demasiada licencia de arte?

    • Jac Goudsmit dice:

      Al menos WDC recibe una mención como "la empresa que creó el 6502" (sí, sé que debería ser el 65C02).

      Pero el artículo da un salto gigante del Sistema 1 al BBC Micro, saltando al menos el Gland Atom pero posiblemente otros.

      Bien hecho; hay muchas otras fuentes con versiones más precisas y completas de esto y más.

      === Jac

      • Kaz dice:

        Puede brillar sobre el Sistema 2-5 y Atom, pero esos sistemas eran todos sistemas basados ​​en * 6502, por lo que no hay un desarrollo significativo en la CPU.

        * Había una tarjeta CPU 6809 disponible para el sistema, pero esto tuvo un impacto marginal en el desarrollo del ARM. Se puede decir que hizo que Acorn incluyera el Tube en BBC Micro para conectar coprocesadores externos (que se usaron para desarrollar el ARM), pero eso entra en una historia más profunda que solo describir la filosofía RISC / ARM.

  • Lou dice:

    Un poco omitida está la ventaja más importante de RISC, que es que cada instrucción (presumiblemente) toma el mismo número de ciclos de reloj, lo que permite hardware de canalización y posiblemente una arquitectura de ejecución súper escalar. Simper es mejor si uno tiene que anticipar las paradas de los conductos (aquí prevalece la arquitectura de carga / almacenamiento, a diferencia de la arquitectura de memoria de registro) y mantiene el diseño del dispositivo manejable. Lo contrario de esto es X86, que es una pesadilla con una locura de ciclo de reloj variable de duración variable. Si observa (un poco) lo que Intel y AMD hicieron para hacer realidad este sueño inducido por LSD de un chip x86 con instrucciones de gran escala y múltiples núcleos, eso lo volvería loco. Sin embargo, extrañamente, ellos (CISC-ish) X86 ganan la batalla de la CPU.

    • Megol dice:

      Realmente publicaste esto en la persona equivocada artículo. Las instrucciones ARM tienen una latencia muy variable, este no es el MIPS original.
      Ejemplos:
      LDM / STM
      MUL / MLA

      X86 no cambia nada cuando se trata de diseño multinúcleo. El modelo de memoria es mejor que cualquier RISC, lo que reduce las complicaciones.
      El principal problema es la decodificación y los proyectos modernos utilizan el paralelismo para abordar el problema de la decodificación de longitud. Cuando se conocen las longitudes de las instrucciones, cada instrucción puede enviarse a un conjunto de decodificadores paralelos. No es simple, por supuesto, pero aparte de un poco más de consumo de energía y un poco más de demoras en la decodificación (ocultas principalmente por las predicciones de sucursales líderes en la industria), la superescala x86 no es un gran problema.

      • Alphatek dice:

        ARM v1 no tenía MUL o MLA; venían con v2.

        Steve Furber, también, fue apenas segundo - mira su trabajo en Amulet y últimamente algo neuronal.

        Curiosamente, Acorn también estaba considerando cambiarse al i860 en un momento.

        • Kaz dice:

          ARM1 no estaba disponible comercialmente: fue ARM2 el primero que lo hizo salvaje (en Ar Archimedes).

          • Halconero dice:

            El ARM1 se vendió como parte del ARM Rating System, que era uno de los muchos coprocesadores disponibles para el BBC Micro (también estaba disponible como una tarjeta de expansión para una computadora). Fue lanzado en 1986, un año antes del Se lanzó Arimimedo, y estaba destinado a desarrolladores que pretenden comenzar a escribir programas para la nueva máquina.

      • Lou dice:

        ¿Crees que el modelo de memoria del X86 es mejor que el de ARM? ¿En serio? ¿Segmentar y compensar?

        si miras la referencia instructiva

        http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0439b/CHDDIGAC.html

        Verá que la mayoría de las instrucciones funcionan en 1 ciclo. Las principales excepciones
        son instrucciones "repetidas" como las a las que te refieres, que mueven varios registros a la memoria,
        e instrucciones que provocarán un bloqueo del conducto. (cómo multiplicar y dividir) Además, casi todo
        Las instrucciones de brazo están codificadas en un formato muy rígido, los primeros 4 bits son banderas condicionales, luego
        (aproximadamente) 8 bits de código de opera, 4 bits de registro de origen, 4 bits de registro de destino y posterior
        operando de once bits. Esta longitud fija hace que sea mucho más fácil construir el hardware de ejecución de descifrado.
        Le permite al diseñador de hardware "saber" que puede mostrar todas las instrucciones de una sola vez.
        Lectura de 32 bits de la memoria, lo que facilita la construcción del decodificador de instrucciones.
        El objetivo es crear un conjunto de instrucciones que simplifique mucho el hardware de esa manera.
        menos (reducción de costo / energía) o más para ser utilizado en otras áreas (ALU más anchas y más anchas /
        más registros)

        En cuanto a MIPS, la intención de este diseño era reducir aún más la complejidad del hardware de la CPU.
        (permitiendo así que se usen más transistores como caché y registros) teniendo el compilador
        inserte No-Ops cuando haya una cabina de tubería. Esta arquitectura lleva a la diversión
        acrónimo (R) elige el éxito (I) imposible (S) para el compilador (C). También tuvo el desagradable efecto de lavar
        algo de memoria con un montón de NOP. Los procesadores MIPS modernos manejan la canalización
        cabinas en el interior y ya no necesita los NOP. MIPS también nos trajo el archivo de registro de la ventana,
        intercambiando toda esa lógica de conducto (original) por una arquitectura de grabación tipo FIFO que aceleraría
        llamadas a funciones.

        No estoy diciendo que los diseñadores de X86 no hayan sido increíblemente innovadores en su búsqueda para alcanzar los 40 años.
        un antiguo conjunto de instrucciones X86 de 8 bits para funcionar a 64 bits con paralelismo RISC. Me quito el sombrero ante los equipos y
        equipos de ingenieros inteligentes que construyen estas CPU supercomplejas, asumimos todos los días. Mío
        El punto es que RISC tenía como objetivo aumentar el paralelismo al reducir la complejidad de la instrucción, el comercio
        rara vez se utilizan instrucciones complejas para ejecutar instrucciones más ortogonales de forma más rápida y eficiente.

        • rnjacobs dice:

          No es el modelo de memoria 8086. Búsqueda de "modelo de coherencia de memoria": ARM proporciona De Verdad garantías débiles, y apesta.

          • W dice:

            Cierto hasta alrededor de v7 / v8. Y no tan malo como Alpha, que ha dificultado la programación de múltiples núcleos.

            Hay una muy buena charla de dos horas sobre las "armas nucleares" de Herb Sutter (creo) sobre modelos consistentes del punto de vista de un lenguaje de programación.

        • TheRegnirps. dice:

          Intel ha hecho un progreso que los ha promovido con un ordenamiento extraordinario que realmente funciona y permite la ejecución simultánea de más de una instrucción. Como muchas tuberías. No es un paralelo porque no es la misma instrucción con datos diferentes. Se parece más a hilos. Y al ejecutar desde un caché rápido, nadie lo supera hoy. ¿Alguien se acerca? ¿El Rizen más nuevo?

          La clave de RISC es el tamaño del registro. La investigación de entonces en Berkley (MIPS) y Stanford (SPARC) mostró tamaños óptimos para los registros. MIPS tiene 32 registros y SPARC tenía 32 (pero no todos de propósito general). El SPARC actual de Oracle tiene algo así como 70 a 700 registros de 64 bits dependiendo. ARM tiene 16.

          ARM ha tenido la ejecución condicional muy buena de cualquier instrucción que elimina todas las ramas cortas, aunque hace NOP porque tiene que hacer algo. (¿No en el pulgar?) El registro condicional es el mismo que 65C02 porque funciona y porque hace que la emulación 65C02 sea mucho más fácil.

          Puede administrar las subrutinas usted mismo empujando el contador del programa a la pila (el puntero de la pila y la computadora son parte del registro) o usando las pseudoinstrucciones en un ensamblador. Y hay un modo de interrupción rápida que cambia a un segundo registro, por lo que no tiene que guardar todo el contenido del registro para este cambio de contexto. Es muy rapido. Un ARM moderno podría responder a una interrupción y escribir a GPIO en menos de cinco instrucciones o quizás 10 ns. Eso es 100MHz o más. El código FIQ está al final de la matriz de vectores, por lo que ni siquiera hay una rama. GCC tiene funciones para usar FIQ en C.

          Escuché en Apple que visitaron a Apple sobre el futuro, que dijeron que tenían que visitar el WDC, donde vieron que Mensch básicamente hace que el 65C816 sea el único PLUS, que el 816 era un mashup realmente estúpido que no tiene futuro, y en De camino a casa en el avión decidieron que podían hacer algo mejor ellos mismos. Y tenían razón.

          Se rumoreaba que los hermanos Huston hicieron un prototipo de Apple IIxxx con el primer ARM y resultó muy bien, también copió 65C02 lo suficientemente rápido como para ejecutar todo el código heredado. Pero Jobs no quería más mejoras en la línea Apple II, ya que la Mac era la pieza central (aunque todo el dinero provenía de las ventas de Apple II en ese momento).

          Por supuesto, luego Apple volvió al ARM para Newton y el resto es historia.

  • Ostraco dice:

    “Varios factores influyeron en esta decisión. Una fue una visita a la empresa que fabricó el 6502, donde notaron que una persona estaba trabajando en la próxima versión de esta CPU. "

    Y ahora necesitan equipo, y todavía lo están estropeando.

    • Megol dice:

      También las versiones 6502 tienen errores, diferentes versiones diferentes errores.

      Un procesador moderno es mucho más complejo e incluye mucho más que un antiguo chip de 8 bits. Por eso pueden ser tan rápidos.

    • TGT dice:

      Ahora son un poco más complejos, ¿sabe?

  • Megol dice:

    ARM es un diseño realmente bueno con los componentes correctos elegidos para permitir el rendimiento a un costo (relativamente) bajo.

    Al no ser un diseño RISC limpio, pero admitir cosas como LDM / STM (cargar / almacenar múltiples registros con una instrucción), ejecución condicional y cambio de parche opcional antes de las operaciones de ALU, significaba que podría funcionar bien con el modo DRAM en la página sin caché. Estas características también dieron una muy buena densidad de código para un proyecto RISC.

  • trevor dice:

    Buena cosa. Es interesante ver cuánto más se puede lograr con menos. Cambia la mentalidad.

    • Ren dice:

      Cuando solo tienes un martillo, ¡cada problema parece un pulgar!

      • PirateLabs dice:

        Bela.

      • Elliot Williams dice:

        ¿Pulgar o Pulgar2?

  • biblioteca electrónica dice:

    Mi solución para golpear a los niños con encendedores de pasteles obteniendo juegos gratis de Space Invader (ese era el juego principal) fue colocar una tapa de cerámica de .1uf entre la puerta de la moneda y el interruptor de clic.

    funcionó muy bien!

    demasiado bien, un par de chicos intentaron cortarme, se "cayeron" del entrepiso ...

    • CaptMcAllister dice:

      No sé nada sobre el receptor de banda ancha y las condiciones que lo requirieron descritas en este artículo, pero me parece una exageración masiva.

    • JDX dice:

      Tuve que buscar un "interruptor de clic", así que debido a mis compañeros, que siempre han suplicado obedientemente a sus padres por monedas de veinticinco centavos, obstaculiza los intentos de robar créditos golpeando la moneda. Ejemplo: https://www.twistywristarcade.com/buttons-switches/1157-slam-switch-.html.

  • PirateLabs dice:

    Vaya, esta mujer parece la versión femenina de Woz. Estoy realmente impresionado. También estoy un poco triste por no haber oído hablar de ella antes.

    • Richard Collins dice:

      "También estoy un poco triste porque nunca había oído hablar de ella antes".
      Cambió su nombre de Rodger, por lo que es posible que no haya oído hablar de ella antes. Causó confusión. Muy valiente para ser honesto. A algunos les gustaría usar eso como pretexto para atacarla. Yo digo que seas tú mismo 🙂

      • TGT dice:

        Definitivamente un brillante ejemplo para la comunidad trans. Más gente realmente necesita saber sobre ella.

        • zigurat29 dice:

          qv también Lynn Conway, quien hizo muchas contribuciones, incluido VLSI con Carver Mead
          https://eo.wikipedia.org/wiki/Lynn_Conway
          https://eo.wikipedia.org/wiki/Mead_%26_Conway_revolution

          • EP2018 dice:

            SSI y LucasArts también tenían programadores cruzados. De hecho, lo hicieron un número sorprendente de empresas de informática de los años 70 y 80, aunque a menudo es difícil averiguarlo por sus nombres sin conocer tanto sus nombres como los detalles aproximados de su empresa. historia.

            Las mujeres en la industria durante ese tiempo tampoco son infrecuentes, pero clasificarlas por hombres con nombres de género ambiguos a menudo puede ser difícil (más que unos pocos tipos llamados Kim o Robin u otras cosas, lo que hace que sea fácil suponer que lo fueron (fe ) masculino hasta que vea una foto del equipo y se dé cuenta de que su suposición de género era terriblemente incorrecta.

      • fonz dice:

        Me parece que las mujeres (conocidas o al menos famosas en línea) en la electrónica con un cromosoma Y no son exactamente raras

        • Greenaum dice:

          Podría haber algo relacionado con la alta superposición de transgénero y autismo en los individuos, y la igualmente alta superposición de autismo y ser un nerd, especialmente en cosas complicadas como el diseño de CPU.

      • Lista de Jenny dice:

        Si apoya a la comunidad cruzada, un buen lugar para comenzar es no usar nombres antiguos. Lo llaman "nombre de la muerte" y se usa mucho en su contra.

        • Pete dice:

          Hay aspectos prácticos a considerar cuando los nombres cambian, como han demostrado otros hilos. Cuando haces una búsqueda histórica de Sophie Wilson, simplemente no obtendrás una imagen completa a menos que también conozcas su nombre anterior. Decir que no lo apoyamos si queremos saber que algún "nombre muerto" ignora esta realidad.

          Mi esposa decidió tomar mi apellido cuando nos casamos. Esa es una tradición familiar que ella ha decidido seguir. Sin embargo, nunca dijo que nadie puede usar su nombre nasal y, de hecho, tiene que darlo en algunos documentos. La realidad es que simplemente cambió su nombre legal. Sophie también, excepto que cambió su nombre en lugar del apellido.

          Los nombres históricos proporcionan un contexto histórico. En el caso de Sophie, hay una historia larga e impresionante que vale la pena conocer, pero no se puede conocer a menos que comprenda que solía nombrar otra. Entiendo que los nombres antiguos se pueden usar como insultos contra las personas del otro lado, y lo entiendo, pero obviamente es ridículo que insinúes que revelar su cambio de nombre convierte al Sr. Collins en un fan.

          • Lista de Jenny dice:

            No hay fanatismo implícito, solo digo que todas las personas prefieren que no use sus viejos nombres. No todo el mundo lo sabe, por lo que vale la pena decirlo.

        • rastersoft dice:

          Creo que "usar el nombre antiguo" es muy diferente de lo que hizo Richard. "Usar el nombre anterior" es insistir en llamarla "Roger" en lugar de Sophie, o usar "él" en lugar de "ella", lo cual, creo, no es el caso.

          • Lista de Jenny dice:

            Como le dije al otro comentarista, no hay implicación de una gran culpa, solo para decir que para la mayoría de las personas de Cross, no usar el nombre anterior te convierte en un mejor aliado.

  • halherta dice:

    El caso de RISC frente a CISC se aplica a tareas de montaje simples. En el momento en que desea hacer algo más complicado que agregar o cargar desde / guardar en la memoria, las arquitecturas RISC tienden a quedarse atrás. CISC también tiene sus desventajas. El mejor enfoque es combinar un poco de ambos. Pero este debate tuvo lugar en la década de 1980 y quizás en algún momento de la década de 1990. ¿Por qué todavía lo tenemos? ARM Today no es Pure RISC… .Mucho RISC con algo de CISC. Incluso Intel x86 tiene una combinación de RISC y CISC. No entiendo el propósito de este artículo en absoluto ... Es como si hubiera revivido los años 90.

    La ventaja real de ARM es que los proyectos de hardware a nivel RTL están optimizados para un bajo consumo de energía y, por lo general, cuesta rendimiento. Si observa el consumo de energía de las CPU más prominentes de ARM de Cortex-A72, no están tan lejos del rendimiento similar de Celeron de Intel.

    La otra ventaja de ARM es su modelo de ventas de software IP ... el hecho de que muchos proveedores pueden vender un microcontrolador con la misma CPU Cortex-A / M / R pero diferentes periféricos para una pequeña participación ha revolucionado la industria y ha demostrado ser un enfoque muy exitoso. tanto para ARM como para todos los proveedores de semiconductores que venden microcontroladores basados ​​en ARM.

    • halherta dice:

      Por supuesto, la contribución de Sophie Wilson al diseño de CPU en general es admirable y debe destacarse ... Solo me frustra cuando veo que las viejas ideas se rehacen (especialmente aquí en la-tecnologia) como si fueran nuevas. Tal vez sea una señal de que estoy envejeciendo ...

      • Ostraco dice:

        "Lo que fue, volverá a ser,
        lo que se ha hecho, se volverá a hacer;
        No hay nada nuevo bajo el sol. "

      • TGT dice:

        Sabes que si descartáramos solo nuevas ideas, no habría publicaciones. Las ideas legalmente nuevas rara vez desaparecen. Realmente no he hecho nada nunca antes visto en mi vida, y dudo que mucha gente aquí tampoco lo haya hecho.

    • rnjacobs dice:

      Una de las cosas más humillantes del ARMv1 es que es ocho años más joven que el 68k, pero en lo que respecta a Dhrystones, es solo un 20% más rápido.

      • Andreas dice:

        Según https://en.wikipedia.org/wiki/Instructions_per_second, el 68000 opera a 2188 MIPS a 12.5 MHz mientras que el ARM2 opera a 4 MIPS a 8 MHz. Esto es bastante impresionante, ya que el 68000 tiene aproximadamente el doble de transistores según https://en.wikipedia.org/wiki/Transistor_count

        Tenga en cuenta también que el 68020 funciona con 4,848 MIPS a 16 MHz mientras que tiene 190000 transistores (mientras que ARM 2 tiene 30000). Sin embargo, la comparación es un poco más cercana cuando se compara el área muerta de los chips (ARM 2 tiene 30 mm ^ 2 mientras que 68020 tiene 85 mm ^ 2).

        • rnjacobs dice:

          Comparé Dhrystones por una razón. ARMv1 funciona mucho menos (aproximadamente el 50%) por instrucción que el 68k al mismo tiempo que ejecuta cada instrucción en aproximadamente el 20% del tiempo.

          Necesita alrededor de 800 instrucciones 68k para Dhrystone y 1600 instrucciones ARMv1 para Dhrystone.

          Las primeras ventajas de las arquitecturas RISC fueron el tamaño (es decir, el costo), la eficiencia energética y la facilidad para agregar tuberías ... pero eso es más o menos.

          • rubí pantera dice:

            Parece que la respuesta también fue por razones y planteó puntos más útiles.

            ¿Está diciendo simplemente que un índice de referencia tiene la puntuación del índice de referencia y eso le informa sobre el índice de referencia? Cuando elijo un microprocesador, definitivamente tengo que considerar el diseño completo y todas las ventajas, y ni siquiera miraría una puntuación de referencia fuera de cualquier caso de uso para el número. Si bien la cantidad de instrucciones por reloj que realiza son directamente relevantes, simplemente puedo abrir la hoja de datos y mirar el conjunto de instrucciones para ver qué significa eso para mi código.

          • rnjacobs dice:

            Digo que la medición bruta de MIpS es, por un lado, la métrica más inútil posible.

            Dhrystones son una métrica terrible, pero no obstante son menos terrible ol MIpS.

          • Andy Koenigs dice:

            Las Dhrystones definitivamente están manipuladas. 68000 instrucciones son casi RISC. La única diferencia entre la arquitectura 68000 y RISC es que el 68000 almacena memoria para grabar instrucciones ALU y la memoria se mueve. De lo contrario, 68000 es RISC.

            El principal problema con el 68000 es que se necesitan 4 (a veces 6) ciclos para acceder a palabras de 16 bits de la memoria. El 68000 no puede compensar esa enorme brecha.

    • Julian Skidmore dice:

      "Durante el minuto en que desea hacer algo más complicado que agregar o cargar desde / guardar en la memoria, las arquitecturas RISC tienden a quedarse atrás".

      Esto no es verdad. Todos los primeros procesadores RISC fueron diseñados con lenguajes avanzados, especialmente compiladores, como su principal medio de programación. Lea el volumen principal: "Arquitectura informática, acceso cuantitativo".

      Todos los proyectos de procesadores de la década de 1970 se diseñaron con el objetivo de ser cada vez más fáciles de programar, ya que los programadores son el componente más caro. Por tanto, los procesadores CISC “evolucionaron” bajo la creencia de que aumentar la complejidad del conjunto de instrucciones reduciría la “brecha semántica” entre ensamblador y lenguajes avanzados. Porque cada instrucción hacía más trabajo y el hardware era más eficiente que el software; los compiladores escribirían más fácilmente y generarían código más rápido.

      Es intuitivo, pero incorrecto. Es principalmente erróneo porque es difícil para los compiladores clasificar qué combinación de múltiples formas de instrucción produce el código más rápido / más corto. Lo que desarrollaron Hennessy y Patternson fue que el hardware adicional desperdiciaba recursos con características que eran difíciles de explotar, por lo que diseñaron arquitecturas basadas en funciones que eran fáciles de explotar para los compiladores. El principio es: acelerar el caso común y hacer que el caso complejo funcione. Estos son:

      1. Gran cantidad de registros (el intercambio de datos dentro y fuera de los registros es difícil, como sabe cualquiera que programe un PIC de 8 bits).
      2. Formatos de instrucción mínimos (opciones fáciles de considerar si solo hay 3 y hardware simple de diseñar con poca decodificación).
      3. Instrucciones en una sola longitud (fácilmente visibles hacia adelante si todas son iguales).
      4. Modos de dirección simples.
      5. Load / Store (simplifica la interfaz del bus, simplifica los compiladores).
      6. Tres tratan de operaciones de ALU.

      La decodificación reducida requerida en cada área significaba que podían asignar recursos y acelerar el procesador donde se calculó: donde agregaría ancho de banda de procesamiento. Por lo tanto, entubar la CPU se vuelve relativamente fácil porque todo es regular. Las operaciones ALU de 3 direcciones le permiten hacer algunas cosas 3 veces más rápido. Load / Store le permite desconectar la interfaz de memoria de la ruta de datos de la CPU principal.

      Eso es RISC.

      • TheRegnirps. dice:

        Cargar / almacenar mi cerebro pica. ¿De dónde vino? Todo lo relacionado con las arquitecturas lo llamó una "dirección única".

        Skidmore. Mmm. Julian Skidmore. Algo sobre Forth emerge de la niebla del pasado ... ¿FIG? ¿Cuartas dimensiones? ¿Un MVP?

        • Julian Skidmore dice:

          ¡Hola!

          Cargar / Comprar no es lo mismo que una sola dirección. Una sola dirección significa que hay un campo de dirección en una instrucción, pero podría haber muchos tipos de instrucciones válidas. El PIC 6502, 6800 y 8 bits son todos ejemplos de arquitecturas de dirección única.

          Cargar / Almacenar significa que la interfaz de memoria está separada de la ruta de datos principal, es decir, el acceso al registro principal y las operaciones de ALU. Por lo tanto, la decodificación de la CPU nunca debe determinar si debe esperar a que finalicen los ciclos de generación de direcciones de memoria externa y de captura de memoria.

          Y sí, soy el diseñador de la computadora Forth DIY-AVR basada en Fn. Vendí alrededor de 1000 copias y el último código fuente se envió a github hace unos días (que incluye la serie capa de traslación relámpago; un controlador de video de componentes más eficiente que cualquier controlador arduino; una biblioteca de diapositivas muy compacta; gráficos de mapa de bits sobre SRAM en serie; blitter simple basado en XOR; soporte de interrupción del usuario; control de pila y algunas otras características interesantes)!

      • prueba comp.ark dice:

        Los diseños de RISC tenían una grave desventaja comercial en comparación con los anteriores a CISC x86. La razón fue el costo de la memoria. El diseño anterior a CISC x86 tenía una densidad de código binario mucho mayor. Esto redujo tanto la cantidad como la velocidad de memoria requerida para almacenar y operar código x86 en comparación con RISC. Esta fue una ventaja terrible para x86 hasta finales de la década de 1990, cuando bajaron los precios de la memoria.

        • Julian Skidmore dice:

          Esto no es verdad. Los primeros procesadores de los procesadores RISC eran muy conscientes del costo de la memoria y lo citaron como una de las principales razones detrás de CISC. Juzgaron que la RAM ya era lo suficientemente barata para soportar la menor densidad de código.

          RISC sufrió comercialmente por una sola razón: x86 ya era tan dominante que nadie quería arriesgar nada más. Es la misma razón por la que el 680 × 0 sufrió en comparación con el x86 cuando era claramente superior para la informática comercial.

          • Andy Koenigs dice:

            Estoy de acuerdo. Existe una razón por la que ARM permite condiciones en cada instrucción y por qué el cambiador de barril se puede combinar con casi todas las demás instrucciones.

  • AndreN dice:

    La C en RISC significa "computadora", no "codificación".

    • Julian Skidmore dice:

      En realidad.

    • Julian Skidmore dice:

      De hecho, si miras el primer video, Sophie Wilson dice que significa Complejidad Instruccional Reducida. Esto es nuevo para mi. El artículo original de PCW, donde leí por primera vez sobre RISC (sobre el ARM1 nada menos), lo llamó Computadora de instrucción reducida; el libro "Arquitectura de computadora, acceso cuantitativo" de Hennessy y Patterson dice "Computadora"; nuestro curso de arquitectura de computadoras a fines de la década de 1980 llamado C en RISC “Computadora”.

      • Elmer dice:

        Es computadora, y los otros términos son sencillos. Veo mucho periodismo técnico que ha estado cometiendo este tipo de errores últimamente.

  • Darren dice:

    El tamaño del registro no es el mismo que el del bus de datos ancho. Motorola 68008 tiene un bus de datos de 8 bits pero registros de 32 bits.

    • Julian Skidmore dice:

      Lo que significa que el 68008 es una CPU de 32 bits. Internamente tiene una ALU de 16 bits, pero esto no define su tamaño arquitectónico. Considere la nueva fecha general original. Era una computadora de 16 bits a pesar de tener una ALU de 4 bits y una ruta de datos.

  • Millas dice:

    Buscando, encontré esto, leyendo entre comidas. Busqué la referencia del núcleo del brazo "sin fuente de alimentación", huyendo de las líneas de datos
    https://queue.acm.org/detail.cfm?id=1716385

    • Ren dice:

      Y no vi una mención de "Sophie" Wilson en él.

      • Julian Skidmore dice:

        Sophie Wilson es transgénero.

      • Elliot Williams dice:

        Ella es la "Wilson" en "Wilson y yo garabateamos trabajos de proyectos en trozos de papel ..." y es la otra mitad del "nosotros" después.

  • Duuma dice:

    ¿Qué tal algunos héroes masculinos también? La discriminación es solo eso. La discriminación positiva no existe y estas mujeres pueden resistir bien la competencia.

    • Somun dice:

      entiendo

    • Duuma dice:

      Casi todas las piezas heroicas aquí son sobre mujeres, y Sophie eligió vivir la vida como una. Contar una historia unilateral no soluciona una historia ni una desigualdad. Contar una historia unilateral es falso y crea la desigualdad que busca combatir. Las mujeres no necesitan informes sesgados para verse bien. Sugerir implícitamente que son parte de la historia es solo una continuación de lo que salió mal todo ese tiempo.

      • rnjacobs dice:

        Entonces, ¿cómo sugiere que la gente se enfrente a la eliminación?

        • Duuma dice:

          Parece que vale la pena discutirlo, pero tampoco parece ser parte de esta discusión. No se puede corregir a las mujeres subrepresentadas en gran parte de la historia científica mediante una subrepresentación de hombres. Dos injusticias no justifican.

    • Elliot Williams dice:

      ¡En camino! Recogeremos a Richard Feynman el próximo martes.

    • rubí pantera dice:

      No creo que nunca haya tenido que soportar ninguna competencia, estaba en un grupo ascendido cuando hizo este trabajo y está en un grupo ascendido ahora que eso ha cambiado. Es un poco cuidadoso buscar discriminación en esta historia en particular; si sucedió, ciertamente con alguien más de quien no hablamos todavía.

  • Un dron dice:

    Necesitamos a alguien en el Reino Unido para iniciar "Wilsonfruit Industries" que competirá directamente con "Adafruit Industries" en los Estados Unidos. Requisitos principales: La fundadora debe ser mujer y NO debe teñirse el cabello de rosa (para fines de mercado). Cualquier otro color de cabello es aceptable 😉

    • Ren dice:

      Entonces, ¿eso excluye a Sinead O'Connor?
      B ^)

    • Shannon dice:

      ¿No sería "Sophiefruit Industries"? Ada es un nombre de pila.
      Si fuera "Wilsonfruit", la gente esperaría que el fundador fuera el voleibol.

  • Julian Skidmore dice:

    De la BBC en el evento 30 (¡estuve allí!). Steve Furber habló bien de cómo diseñaron el ARM.

    Al principio optaron por Intel 80286. Sin embargo, no les gustó la arquitectura de bus que pensaban que era demasiado ineficiente (el 6502 puede recordar traer un ciclo, pero el 8086 tomó 4 y el 286 tomó 2 o 3). Fueron a Intel para preguntarles si ellos (Acorn o Intel) estarían dispuestos a producir una versión con una arquitectura de bus más eficiente, pero Intel rechazó la idea. Luego decidieron visitar WDC (en esa época leyendo los artículos de investigación de Hennessy y Patterson, que se convirtieron en Sparc y MIPS) y se sintieron animados por el hecho de que básicamente un tipo había desarrollado una CPU de 16 bits comercialmente exitosa. Aspectos de la arquitectura ARM1 formaron la base del Doctor de Steve Furber (yo formé parte de Amulet durante un tiempo).

    El artículo también es técnicamente incorrecto cuando afirma que el bus de datos del ARM1 tenía 16 bits de ancho. En la entrada del blog de Ken Sheriff, puede ver que tiene 32 pines asignados al bus de datos.

    http://www.righto.com/2015/12/reverse-engineering-arm1-ancestor-of.html

  • Xavier Louis TARDE dice:

    Se me pasa por alto cómo es posible escribir sobre el chip ARM y sin mencionar Arquímedes y la computadora RISC.
    Hay muchos errores en este artículo.
    Si desea obtener más información, consulte los enlaces de este hilo: http://www.stardot.org.uk/forums/viewtopic.php?f=41&t=9602&hilit=remarkable

    • nigeljones dice:

      Vine aquí para decir exactamente esto. Arquímedes impulsó el desarrollo de la arquitectura ARM, no los teléfonos móviles. Bellota no se rindió después de la creación del Maestro ...

  • schlem dice:

    Por lo que escuché ...
    Los X86 y X86-64Bit modernos tienen uno o más núcleos RISC debajo de la capa de control de la canalización.

    Tienen un bus de traducción sobre él para que pueda cumplir con las instrucciones CISC esperadas y el kernel (s) RISC está oculto para el usuario final. Aparentemente, los que están entre las escenas (detallaré más adelante) creen que los kernels RISC tienen diferencias muy diferentes para la generación de CPU de destino y, por lo tanto, sería difícil o imposible hacer un compilador universal que funcione en todas las variantes RISC utilizadas en Intel X86. + Arquitectura X86-64.

    Para detallar mis fuentes, he recopilado este "Conocimiento" * de: la (s) escena (s) de códec de microcódigo, la escena de hackeo del motor de administración Intel (escenas de hackeo de BMC + IPMI) y otras escenas de hackeo generales de Intel / AMD.

    * Ps. Mi mente a veces puede fallar en recordar / recordar cosas correctamente, así que si algo está mal / falta, entonces las correcciones son bienvenidas. 😉

    • chango dice:

      No es un bus, sino una etapa de descifrado que traduce el código de operación tomado a un formato de instrucción nativo.

    • Greenaum dice:

      Pensé que esto era cierto para los proyectos Pentium más antiguos, pero no para los modernos. Los modernos se basan en un teléfono móvil que tenía un diseño más simple (teóricamente) y código CISC x86 operado directamente. Porque las cosas de RISC ralentizaron la ejecución.

  • Alex dice:

    Pregunta: ¿BBC Micro y ARM fueron su mayor contribución o fue el primer módem ADSL?

    https://www.eetimes.com/document.asp?doc_id=1180959

  • John Honniball dice:

    Solda un kit Acorn System One cuando estaba en sexto curso en la escuela en 1979. ¡Mi primer kit de computadora construido! Mi segundo fue un Compukit UK101, también basado en 6502, en 1980.

    • Julian Skidmore dice:

      De hecho, eso apareció en la segunda parte del programa de clic de la BBC que presentó FIGnition!

  • Hola Mundo dice:

    Recuerdo los días en que jugaba a Repto en una microcomputadora de la BBC en la escuela. Todos lo jugaron por falta de una mejor opción. Tuve la música de fondo más molesta y todavía a veces se queda en mi cabeza.

    • Greenaum dice:

      ¡Recuerdo la Torre Martello! El único juego de la BBC que teníamos en la escuela. Finalmente lo completé en algún momento de mis 30. En mi propia computadora con un emulador, dejé la escuela hasta entonces.

  • Elmer Croan dice:

    La mayor omisión en este artículo es que asumieron que durante el tiempo requerido para la computación móvil, y el destino de ARM despegó, no sucedió nada en la batalla de RISC contra CISC. La verdad es que la computadora de Microsoft puede haber usado las CPU de Intel que eran Computadoras de instrucción complejas o CISC, pero casi todo el Business Station y Unix Server Business de Digital Equipment Corporation (DEC) ALPHA, Sun Microsystems (SUN originalmente y ahora ORACLE) SPARC , TANDEM-NO-STOP utilizando los primeros procesadores Silicon Graphics MIPS después de Hewlett Packard su PA-RISC. Por último, debería mencionar UP y su línea PA-RISC de Unix Servidores. IBM ha jugado un papel más pequeño con sus chips POWER desde que Apple cambió de RISC a CISC, pero el enfoque reciente en Linux los está reorientando en RISC.

    No descarto la importancia de ARM en el mundo moderno impulsado por los teléfonos móviles y su tecnología porque ciertamente merecen ese crédito. Solo me importa que el autor del artículo, al tratar de elogiar a la Sra. Wilson, haya pasado por alto al gran grupo de científicos informáticos que también se movieron en contra del paradigma CISC, que ignoró por completo las ideas presentadas por el padre informático Alan Turing de que los conjuntos de instrucción deberían ser tan simples como sea posible.

Maya Lorenzo
Maya Lorenzo

Deja una respuesta

Tu dirección de correo electrónico no será publicada.