1 Kommentare

 
GN⁺ 2024-01-06
Meinungen auf Hacker News
  • Ich habe den Fließtext mit TeX neu gesetzt und für Interessierte ein besser lesbares PDF erstellt: https://github.com/guidoism/tex-oberon

    • Schön. Es sollte eine Möglichkeit geben, das Papierformat ohne großen Aufwand zu ändern; ich würde es gern auf A5 umstellen und selbst als ordentliches Buch binden lassen.
    • Ich frage mich, ob man mit dieser Version des Buchs alles Schritt für Schritt nachbauen kann. Ich würde gern wissen, ob man nicht das ursprüngliche FPGA-Board braucht, das Wirth verwendet hat.
  • Danach lohnt sich auch ein Blick auf Oberon System 3. Es kombiniert das Gadgets-Komponentenmodell mit JIT/AOT-Compilern.
    "The Oberon companion - a guide to using and programming Oberon System 3"
    https://www.semanticscholar.org/paper/The-Oberon-companion-a...
    Den Source Code findet man im Rochus-Fork.
    https://github.com/rochus-keller/OberonSystem3
    Außerdem gibt es die Entwicklungslinie hin zu Active Oberon, auch wenn sie nicht direkt von Niklaus Wirth selbst stammt.
    https://gitlab.inf.ethz.ch/felixf/oberon
    Screenshots und das Betriebssystem-Handbuch
    https://gitlab.inf.ethz.ch/felixf/oberon/-/blob/main/ocp/Doc...
    Es gibt auch Component Pascal und die Blackbox IDE, die von einem Startup aus der ETH Zürich entwickelt wurden.
    https://blackboxframework.org/index.php

  • Das ist nur die erste Hälfte des Buchs. Alle Teile und die Software findet man hier: https://people.inf.ethz.ch/wirth/ProjectOberon/

  • Das größte Kapitel der Ausgabe von 1992 behandelte den Compiler, der Oberon-Programme in Code für den NS32032-Prozessor übersetzte; inzwischen ist dieser Prozessor nicht mehr zu bekommen, und seine Architektur lässt sich auch kaum empfehlen. Interessant ist daher die Passage, dass man statt eines neuen Compilers für eine kommerzielle Architektur selbst eine entworfen hat, um Einfachheit und Regelmäßigkeit bis in die Hardware auszuweiten.
    Durch diese Entscheidung konnten nicht nur die Software des Oberon System, sondern auch die Hardware vollständig und präzise beschrieben werden; der Prozessor wird als RISC bezeichnet, und sämtliche Hardwaremodule werden in Verilog beschrieben.
    Ich frage mich, wie das im Vergleich zu Nand to Tetris wäre. Abgesehen davon wirkt es wirklich spannend; ich frage mich, ob es hier jemand gelesen hat.

    • Wie andere schon gesagt haben: Es richtet sich nicht an Anfänger. Man braucht vorher einen Teil, vielleicht sogar den Großteil des Hintergrundwissens aus NAND 2 Tetris.
      Zum Beispiel wirft einen der Prozessorteil in Kapitel 16 direkt mitten in Verilog-Code. Die CPU-Schnittstelle zum Systembus, Register und die Funktionsweise der Multiplikationseinheit kommen sofort.
      Der gute Teil sind die Erläuterungen zu Designentscheidungen und Trade-offs. Das ist wertvoll, weil Niklaus Wirth gegen Ende seiner Laufbahn die Weisheit aus einem ganzen Berufsleben festgehalten hat. Er war ein seltener Universalgelehrter, der sowohl Schaltungen als auch die abstraktere Informatik breit und tief verstand, immer verallgemeinern und Prinzipien begreifen wollte und Entwicklungen im historischen Kontext erklärte.
      Weil es Wirth ist, beruht der Geschichtsunterricht oft auf persönlicher Erfahrung, und genau dadurch entsteht meiner Ansicht nach eine gute Synthese. Zum Beispiel:

      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 ist das perfekte Einstiegsprojekt in diesen Bereich, weil es Hardware-, Betriebssystem- und Compilerdesign abdeckt.
      Als ich es selbst bis zum Ende durchgearbeitet habe, hatte ich allerdings das Gefühl, dass es bei allen Themen an Tiefe und weiterführender Auseinandersetzung fehlt. Aber genau das macht es zum perfekten Einstiegsprojekt.
      An der Universität Tokio gibt es ein ähnliches Projekt, das man als Zwischenstufe nutzen könnte. Siehe das CPU-Experiment: https://ytsmiling.tech/2017/04/02/cpuex.html
      Wenn einem das nicht gefällt, liegt es vermutlich am Mangel an Dokumentation; auf dieser Stufe kann man auch selbst ein Projekt entwerfen. Im Grunde fängt man mit einem CPU-Teilprojekt in Verilog oder einer beliebigen Hardwarebeschreibungssprache an und macht dann mit Betriebssystem- und Compilerprojekten weiter.
    • Project Oberon beschreibt, wie das Endsystem aussieht. Es ist kein Tutorial, das einen Schritt für Schritt von den Grundlagen bis zum fertigen System führt.
    • Wirths RISC-Prozessor ist deutlich einfacher zu erklären und zu programmieren als der TECS-/Nand2Tetris-Prozessor. Ich halte den Nand2Tetris-Prozessor für nahezu unbrauchbar.
      Ich habe in nandgame den Prozess durchlaufen, den Nand2Tetris-Prozessor zu „entwerfen“, und für die Verdrahtung aus Gattern dürfte der Nand2Tetris-Prozessor einfacher sein.
      Aber Wirths RISC-Prozessor dürfte viel leichter auf einem FPGA zum Laufen zu bringen oder mit Verilator zu simulieren sein. Denn er verwendet eine echte Hardwarebeschreibungssprache und nicht etwas, das einer Hardwarebeschreibungssprache ähnelt, wie sie sich jemand ohne Erfahrung im Hardwaredesign vorstellt.
      In Verilog geschrieben könnte der Nand2Tetris-Prozessor vermutlich mit weniger Code auskommen. Er dürfte Chuck Thackers „a tiny computer for teaching“ https://www.cl.cam.ac.uk/teaching/1112/ECAD+Arch/files/Thack... ziemlich ähneln, das wie der Nand2Tetris-Prozessor auf der Data-General-Nova-Architektur basiert.
      Nand2Tetris führt einen von NAND-Gattern bis zu Tetris und einem Bytecode-Interpreter. Oberon dagegen beginnt bei synthetisierbarem Verilog und führt bis zu einem vollständig brauchbaren GUI-Betriebssystem, das seinen eigenen Quellcode erneut kompilieren kann.
      Leider kann man Vivado darauf nicht ausführen, also kann es seinen eigenen FPGA-Bitstream nicht erneut synthetisieren. Wie unten jemand sagte, scheint es aber immerhin die eigene Hardware simulieren zu können.
      Gemeinsam ist beiden, dass es keinen brauchbaren Namen für die Prozessorarchitektur gibt.
    • Die didaktische Aufbereitung ist deutlich schwächer als bei Nand to Tetris. Wenn man Hintergrundwissen braucht, sollte man besser zuerst das lesen und danach dieses Buch.
      Später übertrug Wirth die Hardwarebeschreibung in Lola, eine von ihm selbst entwickelte HDL.
  • In den letzten fünf Jahren ging mir die Idee eines Lerncomputers nicht aus dem Kopf.
    Wenn man an moderne Hardware und Betriebssysteme denkt, ist es praktisch unmöglich, eine Maschine zu haben, die einfach genug ist, um sie der jüngeren Generation beizubringen. Fantasy-Konsolen wie pico-8 sind eine gute Wahl fürs Programmieren, eignen sich aber nicht, um die darunterliegende Hardware zu verstehen.
    Deshalb werden in Schulen wohl immer noch alte Architekturen für den Unterricht verwendet.

    • Eine minimale RISC-V-Implementierung ist ziemlich einfach. Es gibt auch die RISC-V-Implementierung von xv6. Allerdings braucht man etwas mehr als eine absolut minimale RISC-V-Implementierung, konkret CSR, M/S/U-Modi und Paging.
      Wenn kein paged Memory nötig ist, reichen auch M-Modus und U-Modus. Ich habe in so einer Konfiguration ein kleines Echtzeitbetriebssystem für einige WCH-Mikrocontroller. Es nutzt zwar PMP, aber selbst das ist nicht zwingend erforderlich.
    • Vintage-8-Bit-Hardware ist sehr leicht zu verstehen und vermittelt Grundlagen, die auch heute noch direkt relevant sind.
      Ben Eaters YouTube-Videos sind dafür hervorragend. Sowohl sein 6502-Projekt als auch der selbstgebaute Computer, der auf einem Breadboard „von Grund auf“ entsteht, sind gut.
    • Ein Computer, mit dem man irgendwie lernen kann, mit anderen Computern zu kommunizieren, wäre wohl die ultimative Lösung.
      Dank LLMs ist das jetzt in greifbare Nähe gerückt; die verbleibende Aufgabe dürfte sein, die Computer irgendwie zu verbinden, also das Problem der Hardware-Kompatibilität. Auf der Software-Seite müsste man die Software der Gegenseite in irgendeiner Form verstehen können.
  • Die Seiten 59 bis 75 behandeln eine schnelle Implementierung einer Piece List. Das war kürzlich auch ein Thema auf HN.
    Ergänzend dazu gab es auf HN mehrere Threads über Darstellungsformen von Textpuffern für schnelles Editieren:
    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

  • Möge Professor Wirth in Frieden ruhen.
    Nebenbei: Könnte man diesen Link besser taggen, damit sichtbar ist, dass es sich um eine PDF-Datei handelt? Die Quelle sieht vertrauenswürdig aus, aber ich werde immer nervös, wenn eine URL zu einem PDF führt.

    • Sein Appell für lean software ist immer lesenswert.
      [1] https://cr.yp.to/bib/1995/wirth.pdf
    • Links, die normalerweise zu PDFs führen, bekommen am Ende [pdf] angehängt.
    • Mich würde interessieren, was dich an PDF-Dateien konkret beunruhigt.
    • Die URL endet bereits auf .pdf.
  • An der Uni habe ich in einem Compiler-Kurs einen Oberon-Compiler geschrieben.
    Die ursprüngliche Kursseite finde ich nicht mehr, aber diese Seite mit Material von ein paar Jahren vor meiner Zeit scheint ungefähr zu passen: https://cseweb.ucsd.edu/~wgg/CSE131B/
    Als Lehrsprache war es hervorragend.

  • Das ist ein echtes Juwel. Ich frage mich, ob es Versuche gibt, Oberon als mobilen „Computer“ wiederzuverwenden.

  • Ich frage mich, ob jemand das Buch aktualisiert hat, damit man mit neueren FPGA-Boards arbeiten kann.