Linux/4004: iniciar Linux en un Intel 4004 sin fines comerciales

• Debian Linux se inició en una placa real que usa como único CPU el Intel 4004 de 4 bits de 1971, mostrando el límite extremo de los microprocesadores antiguos y de la estratificación del software
• Linux no se ejecuta directamente en el 4004, sino que arranca sobre un emulador de MIPS R3000/DECstation 2100 hecho en ensamblador para 4004, y parte del disco y de la consola se simplifican con hipercalls y controladores paravirtualizados
• Debido al límite de 4 KB de ROM, las operaciones de 4 bits, la ausencia de operaciones lógicas, la poca profundidad de la pila de llamadas y el direccionamiento particular de la RAM 4002, fueron necesarias soluciones alternas como banca de ROM, lookup table, status nibble y RAM virtual basada en PSRAM
• Tras la optimización, el tiempo estimado para iniciar Linux en un 4004 real a 740 KHz es de 4.76 días, y la placa construida fue overclockeada a 790 KHz, con el MIPS virtual funcionando a unos 74.73 Hz
• El resultado fue diseñado como una placa de arte retro para colgar en la pared, e incluye VFD de 40x2, 32 LED de PC, tarjeta SD, SPI PSRAM y UART; el código fuente y las imágenes de disco se publican con condición de uso no comercial

---

Iniciar Debian Linux en un 4004 real

• Linux/4004 es un proyecto que inició Debian Linux en una placa real que usa al Intel 4004 de 1971 como único CPU
• El 4004 es presentado como el primer microprocesador producido comercialmente en el mundo, y en el proyecto se usaron chips Intel 4004 reales de la década de 1970
• El video de demostración fue reproducido con velocidad variable por secciones para reducir el aburrimiento, y el reloj y calendario en pantalla son correctos
• También se ofrece por separado un video de carácter original reproducido a velocidad constante

Por qué el 4004

• En 2012 se ejecutó Linux en un microcontrolador AVR de 8 bits, logrando el récord de “ejecutar Linux en las especificaciones más bajas”, y después también se desarrolló el proyecto más práctico LinuxCard
• En 2023 aparecieron intentos de superar ese récord basado en AVR y un proyecto para iniciar Linux en un MOS 6510, por lo que el objetivo pasó a ser un CPU de nivel todavía más bajo
• Para ir más atrás que los candidatos Intel 8080 y 8008, se eligió el Intel 4004 de 1971
• Como el 4004 es un chip de 4 bits, permite establecer con claridad un estándar más bajo que el de un CPU de 8 bits

Restricciones del Intel 4004

• El 4004 opera en unidades de 4 bits y la mayoría de las instrucciones son de 1 byte y se ejecutan en 8 ciclos de reloj
  • Algunas instrucciones de 2 bytes requieren 16 ciclos
  • FIN es una excepción: aunque es una instrucción de 1 byte, tarda 16 ciclos
• El conjunto de instrucciones no incluye operaciones lógicas como AND, OR, XOR y se basa principalmente en ADD y SUB
• El carry flag funciona de forma peculiar: en la entrada de SUB actúa como borrow, y después de SUB como not borrow; esto fue verificado en hardware real
• Los registros internos son 16 de 4 bits, el PC es de 12 bits y la pila de retorno por hardware tiene 4 niveles
  • Como la entrada superior actual de la pila se usa como PC, en la práctica el anidamiento máximo de funciones es de 3 niveles
• No hay interrupciones, y lo más cercano al manejo de eventos externos es sondear el pin TEST mediante saltos condicionales

Estructura de memoria y E/S

• El 4004 no maneja directamente las instrucciones de memoria; chips conectados al bus como 4001/4002/4289/4265/4308 decodifican y ejecutan esas instrucciones
• El 4001 es un chip ROM con 256 bytes de mask ROM y un puerto de E/S de 4 bits; el contenido de la ROM y la configuración del puerto quedan fijos en fabricación
• El 4002 es un chip RAM con 320 bits de DRAM, circuito de refresh y un puerto de salida de 4 bits
  • Un banco de RAM puede estar compuesto por 4 chips 4002
  • Cada banco de RAM tiene 256 nibbles direccionables directamente y, aparte, 64 status nibble de acceso separado
• El 4289 es un controlador ROM que combina las funciones del 4008 y el 4009, permitiendo conectar el 4004 con EEPROM/EPROM de 5 V con relativa facilidad
• El acceso a memoria requiere un procedimiento de varias etapas: seleccionar banco, cargar la dirección en un par de registros, enviar la dirección al bus con SRC y ejecutar RDM/WRM
  • El status nibble fue útil para acceder rápidamente a datos frecuentes y ayudó a aumentar en alrededor de 30% la velocidad del emulador MIPS

Preparación de la placa de desarrollo y del emulador

• La placa de desarrollo inicial para validación estaba compuesta por un generador de reloj 4201, CPU 4004, RAM 4002-1, controlador ROM 4289 y un ATMEGA48 que hacía el papel de ROM
• La alimentación comienza en 5 V, y al conectar a tierra el polo positivo de un convertidor elevador aislado de 5 V a 10 V se generó una fuente de -10 V para alimentar los chips MCS-04
• El primer programa para 4004 fue código para hacer parpadear un LED conectado al pin de salida 0 del 4002, y funcionó tras aumentar el límite de corriente
• Antes de fabricar la placa real, se escribió un emulador del 4004 llamado u4004
  • Emula no solo el núcleo del 4004, sino también una tarjeta SD virtual, SPI UART, VFD, disposición de 4002 y LED de PC
  • Se usó para validar primero el estado de los pines SPI y el comportamiento de los periféricos, cosas difíciles de depurar en hardware real

En vez de ejecutar Linux directamente, se emula MIPS

• Linux no puede ejecutarse directamente en el 4004
  • No existe un compilador de C para el 4004 y, por las restricciones de la arquitectura, se consideró difícil cargar directamente el kernel de Linux
  • El anidamiento de llamadas, el espacio de direcciones de ROM/RAM y los límites de las operaciones de 4 bits impiden la ejecución directa
• En su lugar, se escribió sobre el 4004 un emulador de MIPS R3000, y sobre él se inició Linux para DECstation 2100
• Se eligió MIPS porque era más fácil de emular dentro del espacio de código del 4004 que otros candidatos
  • ARM tiene muchos operandos de desplazamiento arbitrario
  • Se consideró que RISC-V sería lento por su modo de direccionamiento
  • En x86, solo la decodificación de instrucciones podría superar los 4 KB
  • PPC es demasiado complejo
• El objetivo inicial era meter el emulador completo dentro de los 4 KB de ROM direccionables por defecto del 4004

Soluciones alternativas en la implementación del emulador MIPS

• Solo la decodificación de instrucciones MIPS ya consumía bastante espacio de ROM
  • La tabla de despacho de 64 opcodes de nivel superior requiere 128 bytes
  • Incluyendo subtablas adicionales, la decodificación principal necesitó 359 bytes
• Los 32 registros de 32 bits de MIPS suman 1024 bits, es decir, 256 nibbles desde la perspectiva del 4004, ocupando un banco completo de RAM
• El TLB de MIPS tiene originalmente 64 entradas, pero como Linux no exige exactamente 64, se redujo a 16 entradas
  • La cantidad de entradas del TLB también se diseñó para permitir configuraciones de 4, 8, 12 y 16 entradas
• Como el 4004 no tiene operaciones lógicas, AND/OR/XOR/NOR se implementaron con sumas, carry, desplazamientos y bucles
  • Más adelante, cuando hubo más espacio de ROM, se optimizaron con lookup table de 256 entradas
• Los desplazamientos también tuvieron que implementarse solo con instrucciones de rotación de 1 bit a través del carry del 4004, y luego se mejoraron con copias por nibble y hasta 3 desplazamientos de bit
• El manejo del registro $zero de MIPS aprovecha la característica de pila de retorno circular del 4004 para ahorrar espacio de ROM
  • Cuando el destino es $zero, no se hace return, sino que se pasa al procesamiento de la siguiente instrucción, ahorrando 3 bytes y 3 ciclos por sitio de llamada

Banca de ROM y mejoras de rendimiento

• Con solo 4 KB de ROM no cabía el código para manejar SD, PSRAM, VFD y UART, así que se usó una ROM de 8 KB dividida en dos bancos
• El cambio de banco ROM se controla con el pin de salida del 4002, y se colocaron veneers para permitir call/return entre bancos
• Una vez ampliado el espacio de ROM, fue posible optimizar el rendimiento
  • AND/OR/XOR se implementaron cada uno con lookup table de 256 entradas
  • Usando una lookup table de multiplicación por nibble, la multiplicación se volvió 8 veces más rápida que la implementación anterior a nivel de bit
• La lookup table de operaciones lógicas aprovecha la característica de que JIN en el 4004, cuando está al final de una página ROM, salta tomando como referencia la página siguiente
• La tabla de multiplicación se implementó combinando la lectura de datos byte de la ROM mediante FIN con una técnica para evitar el manejo de la entrada 0

Configuración final del hardware

• La placa final fue diseñada como una placa artística centrada en through-hole con estética de los años 70
  • Incluye traces gruesos en ángulo recto, sin vias, orificios para colgar en la pared y un display VFD
• Los componentes principales son los siguientes
  • CPU 4004 o 4040
  • Generador de reloj 4201
  • Chips RAM 4002
  • Controlador ROM 4289
  • EEPROM
  • 1 o 2 SPI PSRAM
  • Ranura para tarjeta SD
  • SPI UART SC16IS741A
  • VFD 40x2
  • 32 LED indicadores de PC
• La SPI PSRAM se usa como RAM MIPS virtual
  • La primera PSRAM requiere al menos 4 MB porque debe cargar el kernel de forma continua
  • La segunda PSRAM puede dejarse vacía o instalarse con cualquier tamaño arbitrario de 128 KB o más
• Se usó una Futaba M402SD10FJ como VFD, y se indicó que la Noritake CU40025-UW6J es compatible
• El UART se eligió como un componente de montaje superficial SC16IS741A debido a las limitaciones de control de flujo del MAX3100, que era un candidato SPI UART through-hole

Energía y level shifting

• Los componentes MCS-04 usan voltajes peculiares de la familia -15V y lógica invertida
  • A nivel de sistema, es más simple pensar en ello como una alimentación de -10V y +5V
• La placa recibe +5V mediante un conector de borde USB-C y también genera +3.3V y -10V
• El regulador step-down de +3.3V está basado en LM2574
• La alimentación de -10V se cambió a una configuración con MAX774, FET externo, diodo grande e inductor grande porque el MAX764 de la primera revisión no podía suministrar suficiente corriente
  • Al final entrega más de 700 mA a -10V y el ripple es menor de 200 mV
• El level shifting para convertir la salida del 4002 al dominio de 3.3V fue difícil, y se resolvió con una combinación de pulldown de 10K, resistencia de 2.7K, clamp TVS y divisor resistivo

Herramientas de depuración y fallas reales

• Como el 4004 no tiene funciones de depuración integradas, se capturó el bus MCS-04 durante largos periodos con Saleae Logic
• Se escribió un decoder del bus MCS-04 para analizar el estado del bus, la dirección ROM, el valor leído de ROM, el desensamblado y los valores de lectura/escritura de RAM/I/O
  • Después se aportó a Saleae y quedó incluido en el software general de Saleae
• En la placa revision 1.1 había un problema raro donde los caracteres de salida ocasionalmente se corrompían
  • Por ejemplo, i se veía como h y C como B, como si desapareciera el bit menos significativo
• El análisis confirmó una falla en la que, durante el memcpy() del kernel, el bit inferior de cierto nibble en el chip 4002 donde se guardaba el $t1 emulado a veces caía de 1 a 0
• Tras reemplazar ese 4002, la salida de texto volvió a la normalidad

Ruta de arranque

• El firmware primero sondea cuántos chips de memoria hay en el tercer banco de RAM para determinar la cantidad de entradas TLB
• Luego inicializa el VFD, el UART y la tarjeta SD
  • Si falla la inicialización de la tarjeta SD, muestra "Failed to init SD card. Halting here and now!"
  • Esa cadena es la única cadena en todo el firmware
• El firmware no usa una ROM virtual; en su lugar, carga el primer sector de la tarjeta SD en 0x80000000 de la RAM y luego salta allí
• El loader de 446 bytes del primer sector busca una partición de tipo 0xBB en la tabla de particiones, la lee en 0x80001000 y salta a ella
• El segundo loader mide alrededor de 14 KB y está escrito en C
  • Monta la partición activa como FAT12/16/32
  • Parsea vmlinux como ELF, lo carga en RAM y salta al entrypoint
  • Pasa el tipo de máquina, un valor mágico, el mapeo de RAM y una tabla de callbacks para impresión por consola temprana

Disco y acceso a la tarjeta SD

• El acceso a disco usa un driver de disco paravirtualizado PVD como el del proyecto LinuxCard
• En vez de emular en assembly de 4004 un chip SII SCSI y un disco SCSI, las hypercalls de lectura/escritura de sectores actúan como DMA desde la perspectiva del MIPS virtual
• Toda la RAM de la placa Linux/4004 es de 440 bytes incluyendo el status nibble, o 352 bytes excluyéndolo
  • El estado de los registros MIPS y la TLB ocupan una gran parte cada uno, así que no hay espacio para un buffer de sector SD de 512 bytes
• Los datos del sector SD no se guardan en la RAM del 4004; se leen directamente a la PSRAM o se escriben desde la PSRAM a la SD usando buses SPI separados para la tarjeta SD y la PSRAM
• Leer o escribir un sector SD tarda algo más de 1 segundo
• Los requisitos de timing de inicialización ACMD41 de la especificación SD no podían cumplirse con SPI bit-banging, pero las tarjetas SD probadas sí se inicializaron incluso a 5 KHz y con intervalos de más de 200 ms

Velocidad de ejecución y resultados de optimización

• Tras emular la tarjeta SD real y la SPI PSRAM, el tiempo de arranque inicialmente estimado era de 8.9 días con un 4004 a 740 KHz
• Los principales resultados de optimización fueron los siguientes
  • Operaciones lógicas y lookup table de multiplicación: 8.4 días
  • Unrolling del bucle de envío/recepción de nibbles de la PSRAM: 7.25 días
  • Copia de memoria especializada y unrolling de bucles: 6.63 días
  • Eliminación del área de almacenamiento de instrucciones actuales y seguimiento de liveness: 6.50 días
  • Mejora de shift: 6.19 días
  • Unrolling del bucle de envío de direcciones de la PSRAM: 6.01 días
  • Reducción de la config del kernel Linux, ajuste de consola dummy 1x1 y uso de tiny init: 5.33 días
  • Eliminación del soporte para block devices de más de 2 TB y desactivación de la feature huge_files de ext4: 4.81 días
  • Fast path dedicado al instruction fetch: 4.76 días
• Un arranque de 4.76 días equivale a una máquina MIPS de unos 70 Hz con un 4004 a 740 KHz
• La placa fabricada usa el 4201 en modo divide-by-7 y un crystal de 5.5296 MHz, por lo que está overclockeada a 790 KHz
• La mezcla de instrucciones del 4004 en la placa Linux/4004 es 8.8% de instrucciones de 16 ciclos y 91.2% de instrucciones de 8 ciclos, con una velocidad efectiva de 90,640 instrucciones/s
• La interrupción virtual de timer es de 16 Hz y entrega una IRQ cada 65,536 instrucciones virtuales, por lo que la CPU virtual se percibe como de 1.05 MHz
  • El guest MIPS realmente emulado corre a unos 70 Hz a 740 KHz y a unos 74.73 Hz a 790 KHz
  • El tiempo se expande 14,030 veces, y 1 segundo virtual equivale a unas 3 horas 54 minutos reales

Configuración de Linux y experiencia de uso

• El kernel Linux se redujo a unos 2.5 MB eliminando subsystems, filesystems y configuraciones innecesarias como TCP/IP
• Si se usa solo init=/bin/sh, la sesión queda sin session, $PATH, /proc, /sys, etc., por lo que se escribió un tiny init llamado /sbin/uMIPSinit
  • Monta /proc y /sys
  • Configura el hostname y $PATH
  • Vuelve a ejecutar sh cada vez que termina
• Incluso con solo 4.5 MB de RAM, por ejemplo un chip de 4 MB más uno de 512 KB, puede arrancar hasta el prompt de shell sin swap
• Si se activa swap, es posible compilar el código fuente del kernel en el propio dispositivo
  • Se estima que compilar el código fuente del kernel tomaría varios años
  • Gracias al journal de ext4, el plan es recuperar el filesystem tras un corte de energía y reanudar la compilación después de reiniciar

Objetivo como placa artística

• Este proyecto tuvo desde el principio un objetivo artístico parcial
• La placa fue diseñada para colgarse en la pared y cuenta con VFD, layout de PCB de estilo retro y LED de PC
• Incluye un programa que dibuja el conjunto de Mandelbrot en modo texto en el VFD y en el puerto serial
  • La versión de punto flotante /root/mandelbrot tarda unos 30 días en dibujar una imagen de 13 filas por 40 columnas porque Linux debe emular las operaciones de punto flotante
  • La versión solo de enteros /root/mandelbrot_nofp termina en menos de 9 horas

Costo de los componentes y reproducibilidad

• Como uno de los objetivos importantes era que otras personas pudieran reproducirlo, se evitó el 4265, que es difícil de conseguir
• Se eligió el 4201 porque es más simple que un circuito de reloj alternativo, y el 4289 porque es más fácil de conseguir que la combinación 4008+4009
• La placa fue diseñada para poder montar también un 4040 en lugar de un 4004, y como no se usan las funciones adicionales del 4040, se mantiene la compatibilidad con el 4004
• Los chips 4002 para la TLB pueden instalarse en cantidades de 1, 2, 3 o 4 para usarse respectivamente como una TLB de 4, 8, 12 o 16 entradas
  • Si la cantidad de entradas de la TLB es pequeña, el rendimiento baja
  • Ese banco también se encarga de los 16 bits altos de los LED de visualización del PC, por lo que si solo se instala una parte, algunos LED no funcionarán
• Los componentes de los años 70 son caros
  • El 4004 cuesta alrededor de $250
  • El 4040 cuesta alrededor de $60
  • El 4201 cuesta alrededor de $50
  • El 4002-1 cuesta alrededor de $7
  • El 4002-2 cuesta alrededor de $25
  • El 4289 cuesta alrededor de $70
• Los componentes modernos son relativamente baratos, y aunque el SPI VFD puede ser difícil de conseguir, hubo un caso en que se obtuvo en eBay por $15
• También se admite una configuración para interactuar solo mediante el puerto serial, sin instalar el VFD

Proceso de producción del video

• La escena de arranque real se convirtió en video tomando fotografías durante unos 9 días
• Si se toman fotos de 1920x1080 cada 2 segundos, se generan alrededor de 1.76 GB por hora, y una grabación de 9 días da alrededor de 379 GB y unas 388 mil archivos
• Los dispositivos Android tuvieron problemas de cuelgues o sobrecalentamiento durante grabaciones largas, y el iPhone SE3 fue estable para capturar, pero presentó problemas de espacio de almacenamiento y de offload de fotos
• Al final se usó un iPhone 12 Pro Max de 512 GB para grabar todo de forma continua, luego se montó con ifuse en Linux y se copiaron cerca de 400 mil archivos durante más de 10 horas con cp -Rvf
• El video final se produjo con comandos de ffmpeg, y las partes aburridas se procesaron con velocidad variable
  • La velocidad de reproducción varía desde 5 FPS, es decir, 10x en tiempo real, hasta 960 FPS, es decir, 1920x en tiempo real
  • Una versión aparte sin edición usa captura a 0.5 FPS y reproducción a 60 FPS, para una velocidad de 120x en tiempo real

Materiales publicados y licencia

• La imagen de disco para la tarjeta SD se ofrece como descarga separada
• La descarga principal incluye lo siguiente
  • Analizador de bus MCS-04 para el software de Saleae
  • Código fuente del emulador i4004 DECstation 2100
  • Código fuente del MBR de MIPS y del bootloader de segunda etapa
  • Configuración del kernel e información de versión
  • Código fuente del emulador u4004 para la placa Linux/4004
• La licencia es gratis para uso no comercial, y para uso comercial se requiere una licencia aparte
• En cualquier tipo de uso, se debe dar crédito al creador original tanto en forma de código fuente como binaria

[y15un]

Así que el autor original es justamente ese tipo al que esta vez sacaron del escenario en DEF CON por el tema de la badge. No voy a ponerme del lado de nadie, pero aun así de verdad tiene un nivel impresionante.

[GN⁺]

Opiniones en Hacker News

• Vaya, yo pensaba que NetBSD moderno era lento en un m68030 a 15 MHz, bus de memoria de 16 bits y 10 MB de RAM, pero esto sí que es una locura
  Muestra muy bien que, a finales de los 80 y principios de los 90, cuando las computadoras empezaron a tener almacenamiento permanente, espacios de direcciones abiertos y MMU, básicamente llegamos a la computación moderna
  Una Amiga 3000 o una computadora i80486 también pueden ejecutar lo mismo que una computadora moderna; hoy lo hacen muchísimo más rápido o tienen cosas como GPU que entonces no existían, pero funcionalmente no hay una gran diferencia
  Me gusta cómo Dmitry demuestra lo flexible que puede ser la definición de funcional

  • No sé si también pasaba en EE. UU., pero en la Unión Soviética de los 70 y 80 el ajedrez por correspondencia era muy popular
    Las jugadas se enviaban por correo físico, y una partida podía durar meses o años
    Para cuando llegaba la respuesta, uno podía olvidarse de la estrategia original, lo que añadía otro nivel de dificultad al ajedrez; este proyecto es básicamente Linux por correspondencia
    Para cuando salga la salida del comando, uno puede olvidarse de por qué lo ejecutó
  • ¿15 MHz m68030, bus de memoria de 16 bits, 10 MB de RAM? ¿Quizá una Mac LC II? :)
    En realidad, no fue a finales de los 80 o principios de los 90: para finales de los 60 ya era posible
    Creo que también sería posible portar Linux a la IBM Model 67 [1], y quizá hasta sería fácil, ya que GCC ya puede apuntar a ese conjunto de instrucciones
    La MMU también es suficiente, y aunque la restricción de un máximo de 2 MB de memoria de núcleo rápida sería dura, probablemente estaría más o menos en la misma categoría que esa máquina 68030, solo un poco más lenta
    La virtualización completa y los límites de memoria y E/S impuestos por hardware también se inventaron temprano, pero esas funciones tardaron en bajar a las minicomputadoras y microcomputadoras, y tardaron mucho más en ser aprovechadas por el software masivo
    [1] https://en.wikipedia.org/wiki/IBM_System/360_Model_67
  • Esto es básicamente el concepto de completitud de Turing
    Cualquier sistema Turing-completo puede ejecutar cualquier cosa; puede ser extremadamente lento, pero la ejecuta
    Con suficiente tiempo, también podrías correr ChatGPT en un 4004
  • Multicore sí es una diferencia funcional bastante grande
    Es algo parecido a pegarle un auto a una rueda: terminas con tres ruedas más

• La credencial de participante de Hackaday Supercon 2002 (https://hackaday.com/2022/10/12/the-2022-supercon-badge-is-a...) implementaba una CPU virtual de 4 bits y un panel de control donde podías introducir instrucciones directamente, ejecutarlas y hacer ejecución paso a paso
  El panel de control tenía una pantalla donde se podía ver una página de memoria bit por bit, y fue realmente divertido implementar encima un juego de disparos espaciales
  También fue interesante comparar la arquitectura Voya4 con la 4004; había compromisos similares, aunque Voya4 cuenta con la ventaja de 50 años de experiencia en conjuntos de instrucciones de CPU
  Sin embargo, el enfoque de dimitygr no funcionaría en esa credencial, porque tanto la memoria como la RAM están integradas dentro del PIC24 que implementa el emulador de CPU
  Como referencia, las CPU de 4 bits todavía se fabrican y se usan. Muchos controles remotos infrarrojos producidos en masa se programan con MCU de 4 bits. La hoja de datos está en https://www.emmicroelectronic.com/sites/default/files/produc...

  • Es 2022

• Cuando me preguntaban si se podía correr algo en una máquina sin suficiente rendimiento, solía mencionar el ejemplo de AVR, pero ahora tengo un nuevo ejemplo para enlazar
  Viendo la frecuencia y el consumo de energía, me pregunto cuánto RF emite y si se podría detectar y decodificar en la cascada de un SDR
  Todavía lo estoy leyendo, pero hasta este punto veo la palabra “soubroutine”, que parece ser un typo

• Vaya, este proyecto no debe haber salido barato. Gracias a los coleccionistas de eBay
  Y probablemente sea la única situación en la que habría elegido un LCD en vez de un VFD
  Si vas a correr una compilación de varios años, para cuando termine el VFD probablemente estaría destruido por burn-in

  • Personalmente, creo que es un proyecto digno de un doctorado honoris causa
    Lamentablemente, parece que el personal universitario no lee mucho HN

• Vaya, impresionante
  Mirando los bits altos del PC se ve qué se está ejecutando en ese momento
  P. D.: aun así, es más rápido que cargar un kernel desde una ISO virtual en el pésimo IPMI de un servidor al otro lado de Internet ;D

  • Si miras los LED durante el arranque y corres nm sobre vmlinux, puedes mapearlo fácilmente a funciones del kernel
    Después de entrar al espacio de usuario, también puedes distinguir el binario principal (muy por debajo de 0x01000000) y las bibliotecas compartidas (cargadas en direcciones altas, cerca de 0x77000000)
  • Eso de cargar un kernel desde una ISO virtual en el pésimo IPMI de un servidor al otro lado de Internet me recordó cuando intenté arrancar un servidor blade Dell M1000e con una ISO alojada por NFS corriendo en una Raspberry Pi
    Tanto el arranque como la ejecución eran dolorosamente lentos

• Fue un artículo realmente interesante
  Había leído un poco sobre el 4004 y sabía que era un chip extraño, pero el nivel de esoterismo supera lo que imaginaba
  Ahora me dieron ganas de ver qué tan buena CPU se podría hacer hoy con la misma cantidad de transistores
  No son tantos menos que en un 6502, y si fuera de 8 bits sería mucho más fácil de programar

  • Si lo haces con transistores, portaré mi emulador de MIPS ahí :)

• Filmar el video tomó 9 días, y costó 4 horas por cada segundo de emulación
  Y también me pregunto por qué usa Windows 95

  • Es Windows 2000
    Para el video necesitaba una laptop con puerto serial real, no USB
    Esta laptop cumplía con eso y costaba 20 dólares en eBay
    Personalmente, Windows 2000 me parece el Windows más bonito, así que lo instalé para el video de demostración
  • Perdón por la corrección menor, pero la laptop del video parece tener Windows 2000

• Realmente genial
  Me gustaría tener suficientes conocimientos como para entender la mayor parte de este proyecto, pero por ahora fue demasiado difícil para mis limitadas habilidades en ciencias de la computación.
  Aun así, lo más destacado que sí pude entender por completo fue “Section 14.b & 14.c - Getting the data...”.
  Bastaron apenas 400.000 archivos, unas 275 fotos por día durante 4 años.
  Es muy raro vivir en una época en la que, pese a tener tanta capacidad de procesamiento, almacenamiento y red de sobra, las apps de sincronización de medios que parecen ser las más usadas se cuelgan o sincronizan lento, AirDrop falla y ni siquiera existe una función de UI de “seleccionar todo” :)

  • Me pregunto si Dmitry consideró herramientas de sincronización como MobiusSync o Syncthing para copiar continuamente las fotos a la PC apenas las toma.

• Para cosas como esta debería existir algo como un Premio Nobel.

  • Lo más cercano probablemente sea el Ig Nobel Prize: https://en.wikipedia.org/wiki/Ig_Nobel_Prize
  • En computación existe el equivalente, el Turing Award.
    También podrían agregar una categoría de reconocimiento para aplicaciones extrañas e inusuales de la informática.

• En la sección “Why MIPS?” se dice que “algunos inevitablemente son lentos por sus pésimos modos de direccionamiento (RISCV)”; ¿qué problema hay con el modo de direccionamiento de RISC-V?

  • En realidad, es más un problema de formato de instrucciones que de modo de direccionamiento.
    En algunas instrucciones de RISC-V, los bits de los valores inmediatos no se almacenan de forma contigua.
    En las instrucciones MIPS, los bits de valores para suma inmediata, carga de constantes, saltos condicionales, etc., siempre se almacenan en orden.
    En RISC-V, a veces los bits están mezclados.
    Por ejemplo, en un salto incondicional, los bits del desplazamiento de destino se almacenan en el orden bit 19, bits 9-0, bit 10, bits 18-11.
    En hardware, basta con conectar correctamente el cableado, así que el costo de reordenamiento es prácticamente nulo; pero en software hacen falta muchas manipulaciones de bits para corregirlo.
    La razón por la que RISC-V hace esto es simplificar el diseño de hardware.
  • Si no intentas emularlo en hardware extremadamente poco potente, probablemente no sea un gran problema.