- Comparte la experiencia de haber intentado portar el sistema operativo Xv6 en un proyecto universitario usando una CPU basada en una ISA RISC diseñada por ellos mismos y un compilador de C desarrollado por el propio equipo
- El proyecto avanzó construyendo directamente todos los componentes: diseño de CPU, desarrollo del compilador de C (Ucc) y port de Xv6
- Para que el OS funcionara, el equipo se enfrentó al diseño de funciones clave de hardware y software como interrupciones, memoria virtual y caché
- Durante el port de Xv6 surgieron diversos obstáculos, como problemas de portabilidad, dificultades de depuración y bugs de caché, pero lograron resolverlos por su cuenta
- También consiguieron ejecutar aplicaciones interactivas como SL, Minesweeper y 2048, además de un programa de ray tracing, lo que representó un gran logro tanto educativo como técnico
Descripción general del proyecto
- Este proyecto es una práctica emblemática del Departamento de Ciencias de la Información de la Universidad de Tokio, enfocada en que el estudiantado adquiera experiencia con CPU, diseño de hardware, construcción de compiladores y ejecución de aplicaciones
- El objetivo del proyecto era implementar directamente en FPGA la ISA de una CPU diseñada por ellos mismos, crear para ella una toolchain de C (Ucc) y ampliar el trabajo hasta el port de un sistema operativo como Xv6
- La mayor parte del proceso experimental se llevó a cabo mediante aprendizaje autodirigido
Experimento y tareas de la CPU
- Equipos de 4 a 5 personas participaron en el diseño de una nueva arquitectura de CPU, su implementación en FPGA y el desarrollo de un compilador para esa arquitectura
- Uno de los criterios obligatorios de evaluación era llegar a ejecutar un programa de ray tracing después de crear un compilador para un subconjunto de OCaml
- Si quedaba tiempo, podían definir retos propios; algunos estudiantes realizaron experimentos extendidos como acelerar la CPU, desarrollar multicore o ejecutar música y juegos
- El equipo Group 6 se fijó especialmente como meta el port de un sistema operativo, y a partir de ahí se formó un nuevo equipo conjunto llamado Group X
El OS Xv6 y el desafío del port
- Eligieron como objetivo de port Xv6 (basado en Unix v6 y orientado a x86), desarrollado por MIT con fines educativos
- Aunque Xv6 es un OS tipo Unix sencillo, había varios problemas para ejecutarlo en hardware real, como la necesidad de un compilador C89, interrupciones especiales, soporte de direcciones virtuales y una portabilidad limitada
- Xv6 estaba hecho asumiendo características de x86, como
char de 1 byte e int de 4 bytes, lo que provocó muchos problemas durante el port
Desarrollo del compilador y la toolchain (Ucc)
- En el experimento original, el estándar era desarrollar un compilador de OCaml, pero para ejecutar Xv6 necesitaban un compilador C89, así que decidieron crear uno por cuenta propia
- Tomando como base el prototipo de compilador de C de uno de los integrantes, construyeron una nueva toolchain propia llamada Ucc
- Además del compilador, también diseñaron por sí mismos un Primitive Linker y herramientas de depuración
Diseño de la CPU y del simulador
- Tras diseñar el circuito de la CPU con un lenguaje de descripción de hardware (HDL, por ejemplo Verilog / VHDL), lo implementaron en una FPGA real mediante procesos de síntesis lógica con herramientas como Vivado/Quartus
- El proceso repetitivo de síntesis lógica tomaba muchísimo tiempo, por lo que en la práctica implicaba largas esperas
- Después de las funciones básicas de la CPU, también diseñaron aparte el soporte de hardware necesario para ejecutar el OS, como interrupciones, MMU y TLB
- La CPU terminada recibió el nombre de GAIA
- Al simulador se le añadieron interrupciones reales, traducción de direcciones virtuales y herramientas de depuración
Problemas del proceso de port y cómo los resolvieron
- Debido a la baja portabilidad de Xv6, aparecieron comportamientos anómalos según las especificaciones de la CPU y del compilador
- Ejemplo: problemas como la ruptura de operaciones de punteros y de la estructura de la pila cuando
char e int quedaban definidos como de 32 bits
- Mejoraron el compilador Ucc para ajustar
char a 8 bits
- El manejo de interrupciones fue un área especialmente difícil, por lo que añadieron al simulador propio herramientas de depuración como desensamblador y volcado de estado
- El problema de cache aliasing surgía porque GAIA usaba direcciones virtuales como índice de caché, y lo resolvieron introduciendo la técnica de Page Coloring
Resultado final: ejecución del OS y de aplicaciones
- El 1 de marzo lograron finalmente ejecutar Xv6 por completo tanto en el simulador como en la CPU real (hardware)
- Consiguieron correr apps interactivas como mini curses, el comando SL, Minesweeper y 2048
- En particular, para 2048 añadieron diseño de soporte para entrada non-canonical
- Mediante modificaciones a Xv6, añadieron incluso funciones equivalentes a
ioctl y termios al estilo POSIX
- También implementaron un pequeño assembler y mini vi, haciendo posible un verdadero “entorno de programación en tiempo real”
- También ejecutaron el programa de ray tracing sobre el sistema operativo, superando el objetivo original del experimento
Importancia del proyecto y casos posteriores
- Después de este experimento, varias generaciones de estudiantes siguieron creando directamente sus propias CPU y OS para continuar realizando distintos experimentos
- Por ejemplo, extendiéndolo con adopción de ISA RISC-V, OS propio o ejecución de Linux
- A través de la práctica, al experimentar de primera mano toda la pila de hardware/software, mejoraron su comprensión real de algoritmos, integración hardware-software y estructuras de bajo nivel
- Aunque existe la crítica de que “reinventar la rueda” es ineficiente, el efecto de aprendizaje y la diversión de construirlo realmente son muy grandes
Experiencia real y código fuente
Conclusión
- Se destaca la lección de que “no hay mejor forma de aprender que construirlo uno mismo”, junto con la importancia de la experiencia de integración hardware-software
- Las generaciones siguientes también siguen afrontando nuevos objetivos, y esperan que en el futuro puedan ejecutar Linux o una VM sobre una ISA propia
- El relato concluye mencionando los nombres de los integrantes del proyecto
4 comentarios
Qué envidia poder tener una experiencia así en la universidad. Parece que sería muy divertido..
Debió de haber sido muy divertido.
Desplázate un poco más hacia abajo…
¿Hacer una CPU de 8 bits…?
https://eater.net/8bit
Comentarios de Hacker News
Esto me recordó una historia de un proyecto grupal que hice en la universidad hace tiempo, entre tres personas, durante 3 semanas. Entre varios temas, había uno de hacer directamente un sistema operativo muy básico, y les preguntamos a los profesores si nos dejaban portar MINIX3 a Raspberry Pi; nos dieron permiso (pensábamos que sería posible porque MINIX3 ya tenía un port ARM para BeagleBoard).<br>Fue muchísimo más difícil de lo esperado, y empezaron a aparecer problemas técnicos que jamás habíamos imaginado. En especial, sufrimos porque la Raspberry Pi 3 arrancaba en modo hypervisor en lugar de modo supervisor, y la precisión de la emulación de Raspberry Pi en QEMU era tan mala que casi no servía para desarrollar el OS. Pasamos una semana entera atorados en depuración de hardware de bajo nivel buscando una solución. <br>Al final logramos hacer un port funcional con drivers de UART, GPIO y framebuffer, y conseguimos que corriera en Raspberry Pi 2 y 3. Hicimos la presentación en hardware real, usamos un script de shell para mostrar la imagen del ramdisk, monitoreamos los pines GPIO para avanzar o retroceder las diapositivas, y lo controlábamos manualmente cortocircuitando los pines con un cuchillo. En términos de originalidad, fue una presentación abrumadoramente genial, y creo que todavía conservo esa imagen de la tarjeta SD
Suena como una gran experiencia<br>En el momento en que propusieron portar MINIX3 a Raspberry Pi, da la impresión de que los profesores quizá ya esperaban que fracasaran<br>Cuando la precisión de la emulación de Raspberry Pi en QEMU era mala, yo usaba la estrategia de hacer que el OS funcionara primero en QEMU y luego dejar a la suerte el hardware. Aun así, funcionaba bastante bien<br>Tengo curiosidad por saber cómo hicieron la depuración en la Raspberry Pi real
Escuchar que usaste un cuchillo para cortocircuitar GPIO me hizo recordar cuando arranqué una motherboard ATX sin switch de encendido, cortocircuitando dos pines de energía<br>Aun así, tu setup es mucho más genial. Bien hecho
Yo hice algo parecido en SFU hace 25~30 años. No llegamos a montar el OS ni el compilador, y tampoco era un proyecto en equipo<br>Si te interesan este tipo de experimentos, recomiendo Turing Complete, que tiene una guía y tooling bastante accesible. Puedes ir construyendo desde unas cuantas compuertas hasta una computadora real. También se pueden compartir comunidad y componentes, y hasta hay un core RiscV. De verdad es muy divertido; lo recomiendo en Steam<br>Enlace de Turing Complete en Steam
Este post me hizo pensar en un proyecto académico (?) parecido. Si mal no recuerdo, al menos tenía un compilador de C personalizado y un OS personalizado. No recuerdo el nombre exacto
Como referencia, aquí hay un tema relacionado que se publicó antes: enlace al post anterior
Cuando construyes directamente un CPU + compilador + OS, no existe ninguna plataforma subyacente. Yo soy la plataforma.<br>Los bugs se convierten en las leyes del sistema. Normalmente depuras sobre capas de abstracción hechas por otros, pero aquí hasta esas reglas las defines tú mismo. En ese sentido, OP tuvo que depurar sus propias reglas
De verdad es impresionante. Trabajar en la parte low-end suele ser aburrido y tomar mucho tiempo, y es todavía más duro cuando no tienes herramientas esenciales como un debugger
kprintfraro con un osciloscopio, todavía no has probado el verdadero sabor del bajo nivelMagic-1 y BMOW también hicieron algo parecido hace tiempo<br>Para más detalles, ve homebrewcpu.com<br>Para una lista de sitios de gente que construyó su propio CPU, ve homebrewcpuring.org
Ya va siendo hora de que, en vez de implementarlo en FPGA, corras a un laboratorio de semiconductores y les pidas que te fabriquen el CPU directamente