1 comentarios

 
GN⁺ 2024-01-06
Opiniones en Hacker News
  • Recompuse el texto en TeX e hice un PDF más agradable para quienes estén interesados: https://github.com/guidoism/tex-oberon

    • Genial. Parece que debería haber una forma no muy difícil de cambiar el formato de papel; me gustaría cambiarlo a A5 y encuadernarlo yo mismo como un libro decente.
    • Me pregunto si se puede seguir este libro en esta versión y construirlo todo completo. Quisiera saber si no hace falta conseguir la placa FPGA original que usaba Wirth.
  • Después de eso, también conviene ver Oberon System 3. Mezcla el modelo de componentes Gadgets con compiladores JIT/AOT.
    "The Oberon companion - a guide to using and programming Oberon System 3"
    https://www.semanticscholar.org/paper/The-Oberon-companion-a...
    El código fuente puede verse en el fork de Rochus:
    https://github.com/rochus-keller/OberonSystem3
    O también está la línea que llevó a Active Oberon, aunque no fue obra directa de Niklaus Wirth:
    https://gitlab.inf.ethz.ch/felixf/oberon
    Capturas de pantalla y manual del sistema operativo:
    https://gitlab.inf.ethz.ch/felixf/oberon/-/blob/main/ocp/Doc...
    También están Component Pascal y Blackbox IDE, creados por una startup surgida de la ETHZ:
    https://blackboxframework.org/index.php

  • Esto es solo la primera mitad del libro. Todas las partes y el software se pueden encontrar aquí: https://people.inf.ethz.ch/wirth/ProjectOberon/

  • En la edición de 1992, el capítulo más grande trataba sobre el compilador que traducía programas Oberon a código para el procesador NS32032, pero ahora ese procesador ya no se consigue y tampoco es fácil recomendar su arquitectura. Por eso me parece interesante la parte donde dice que, en vez de escribir un nuevo compilador para una arquitectura comercial, decidió diseñar una propia para extender la simplicidad y la regularidad hasta el hardware.
    Gracias a esa decisión, pudieron describir de forma completa y rigurosa no solo el software del Oberon System, sino también el hardware; dicen que ese procesador se llama RISC y que todos los módulos de hardware están descritos en Verilog.
    Me pregunto cómo se comparará con Nand to Tetris. Fuera de eso, se ve realmente interesante; me pregunto si alguien lo leyó.

    • Como ya dijo otra persona, no está orientado a principiantes. Primero vas a necesitar parte, quizá la mayor parte, de los conocimientos previos de NAND 2 Tetris.
      Por ejemplo, la parte del procesador en el capítulo 16 te mete directamente en medio del código Verilog. De inmediato aparecen la interfaz de la CPU con el bus del sistema, los registros y cómo funciona la unidad de multiplicación.
      Lo bueno es la explicación de las decisiones de diseño y los compromisos. Es valiosa porque es la sabiduría que Niklaus Wirth dejó al final de su carrera, basada en toda una vida de experiencia. Fue uno de esos eruditos raros que entendían con amplitud y profundidad tanto los circuitos como la informática más abstracta, y siempre intentaba generalizar, entender los principios y explicar la evolución dentro de su contexto histórico.
      Siendo Wirth, muchas veces la clase de historia se basa en experiencias personales, y creo que gracias a eso logra una buena síntesis. Por ejemplo:

      The second [interface] (MouseX) is included here for historical reasons. It was used by the computer Lilith in 1979, and used the same Mouse as its ancestor Alto (at PARC, 1975). It is distinguished by a very simple hardware without its own microprocessor, which is currently contained in most mice. This goes at a cost of a 9-wire cable. But today, microprocessors are cheaper than cables. We include this interface here, because it allows for a simple explanation of the principle of pointing devices.

    • Nand2Tetris es el proyecto introductorio perfecto para este campo, porque abarca el diseño de hardware, sistemas operativos y compiladores.
      Eso sí, después de hacerlo completo por mi cuenta, sentí que en todos los temas le faltan profundidad y exploración más a fondo. Pero precisamente por eso es un proyecto introductorio perfecto.
      La Universidad de Tokio también tiene un proyecto parecido, y creo que puede servir como puente. Hay que ver el experimento de CPU: https://ytsmiling.tech/2017/04/02/cpuex.html
      Si no te convence, probablemente sea por la falta de documentación; a esta altura, también podrías diseñar tu propio proyecto. Básicamente, empezar con un subproyecto de CPU usando Verilog o cualquier lenguaje de descripción de hardware, y luego continuar con proyectos de sistema operativo y compilador.
    • Project Oberon describe cómo es el sistema final. No es un tutorial que te lleve paso a paso desde los fundamentos hasta un sistema terminado.
    • El procesador RISC de Wirth es mucho más simple de explicar y programar que el procesador de TECS/Nand2Tetris. Yo diría que el procesador de Nand2Tetris roza lo casi inutilizable.
      Pasé por el proceso de “diseñar” el procesador de Nand2Tetris en nandgame, y creo que el procesador de Nand2Tetris probablemente sea más simple de cablear con compuertas.
      Pero el procesador RISC de Wirth debería ser mucho más fácil de hacer correr en una FPGA o de simular con Verilator. La razón es que usa un lenguaje real de descripción de hardware, no algo parecido a un lenguaje de descripción de hardware imaginado por alguien que nunca diseñó hardware.
      Quizá, escrito en Verilog, el procesador de Nand2Tetris tendría menos líneas de código. Se parecería bastante a "a tiny computer for teaching" de Chuck Thacker https://www.cl.cam.ac.uk/teaching/1112/ECAD+Arch/files/Thack..., que se basa en la arquitectura Data General Nova, igual que el procesador de Nand2Tetris.
      Nand2Tetris te lleva desde compuertas NAND hasta Tetris y un intérprete de bytecode. En cambio, Oberon empieza con Verilog sintetizable y te lleva hasta un sistema operativo con GUI completamente usable, capaz de recompilar su propio código fuente.
      Lamentablemente, no se puede correr Vivado sobre él, así que no puede volver a sintetizar su propio bitstream de FPGA. Pero, como alguien comentó más abajo, al parecer sí puede simular su propio hardware.
      Lo que ambos tienen en común es que ninguno tiene un nombre útil para la arquitectura del procesador.
    • La estructura educativa es mucho más débil que la de Nand to Tetris. Si necesitas conocimientos previos, conviene leer eso primero y después este libro.
      Más adelante, Wirth trasladó la descripción del hardware a Lola, un HDL que él mismo creó.
  • Durante los últimos 5 años, la idea de una computadora educativa me siguió dando vueltas en la cabeza.
    Si pensamos en el hardware y los sistemas operativos modernos, es prácticamente imposible tener una máquina lo bastante simple como para enseñársela a las generaciones jóvenes. Las consolas de fantasía como pico-8 son una buena opción para programar, pero no son adecuadas para entender el hardware que hay debajo.
    Por eso parece que en las escuelas todavía se usan arquitecturas antiguas para enseñar.

    • Una implementación mínima de RISC-V es bastante simple. También existe la implementación RISC-V de xv6. Eso sí, hace falta un poco más que una implementación RISC-V absolutamente mínima; en concreto, se necesitan CSR, modos M/S/U y paginación.
      Si no se necesita memoria paginada, se puede hacer solo con modo M y modo U. Tengo un pequeño sistema operativo en tiempo real con esa configuración, orientado a algunos microcontroladores WCH. Usa PMP, aunque ni siquiera eso es estrictamente necesario.
    • El hardware vintage de 8 bits es muy fácil de entender y enseña fundamentos que siguen aplicando hoy.
      Los videos de YouTube de Ben Eater son excelentes para esto. Tanto el proyecto con 6502 como la computadora artesanal hecha “desde cero” en protoboard están muy buenos.
    • Una computadora con la que se pueda aprender de algún modo a comunicarse con otras computadoras probablemente sería la solución ideal.
      Ahora, gracias a los LLM, eso está al alcance, y el desafío restante parece ser conectar las computadoras de alguna manera, es decir, el problema de compatibilidad de hardware. Del lado del software, debería poder entender de algún modo el software de la contraparte.
  • Las páginas 59 a 75 tratan una implementación rápida de piece list. Es un tema que también se trató recientemente en HN.
    Lo agrego porque hubo varios hilos en HN sobre formas de representar buffers de texto para edición rápida:
    https://news.ycombinator.com/item?id=15381886
    https://news.ycombinator.com/item?id=11244103
    https://news.ycombinator.com/item?id=14129543
    https://news.ycombinator.com/item?id=15387672
    https://news.ycombinator.com/item?id=14046446

  • Que descanse en paz el profesor Wirth.
    Como comentario aparte, ¿se podría poner una etiqueta mejor para indicar que este enlace es un archivo PDF? La fuente parece confiable, pero siempre me pongo nervioso cuando una URL lleva a un PDF.

    • Su llamado a favor del lean software siempre vale la pena leerlo.
      [1] https://cr.yp.to/bib/1995/wirth.pdf
    • Normalmente, los enlaces que llevan a un PDF tienen [pdf] al final.
    • Me da curiosidad qué es exactamente lo que te preocupa de los archivos PDF.
    • La URL ya termina en .pdf.
  • En la universidad, en una clase de compiladores, escribí un compilador de Oberon.
    No encuentro el sitio original de la materia, pero este sitio, con material de unos años antes de cuando la cursé, parece ser más o menos el correcto: https://cseweb.ucsd.edu/~wgg/CSE131B/
    Fue un excelente lenguaje educativo.

  • Esto es una joya. Me pregunto si hay intentos de reutilizar Oberon como “computadora” móvil.

  • Me pregunto si alguien actualizó el libro para poder trabajar con placas FPGA más nuevas.