9 ms·

Project Oberon 2013 on RISC-V

140 points by homarp 6y ago

johndoe0815 6y ago
Hi, this port of Niklaus Wirth's Project Oberon (http://www.projectoberon.com http://www.projectoberon.com) to RISC-V (rv32im) is the semester project of my student Rikke Solbjørg at the department of computer science at NTNU in Trondheim/Norway. The system currently runs in a version of Peter de Wachter's emulator modified to use a RISC-V CPU emulation instead of Wirth's RISC5 (now isn't that confusing? ;-)). Rikke's announcement on the Oberon mailing list: http://lists.inf.ethz.ch/pipermail/oberon/2020/015269.html http://lists.inf.ethz.ch/pipermail/oberon/2020/015269.html To answer the obvious question right away: yes, we are working on a FPGA implementation :-). Happy to answer your other questions...
- pjmlp 6y ago
  Just to congratulate everyone involved. Any thoughts about pursuing similar endeavours with System 3? System 3 is closer to modern systems in L&F, which could make some students feel more inspired to delve into Oberon based platforms. Just as an idea for other upcoming projects, I guess.
  - johndoe0815 6y ago
    We are currently discussing a number of ideas for a followup project in addition to creating an FPGA version... I'm currently digging through the 1992/2005 edition of the Project Oberon book (for the National Semiconductor 32k-based Ceres workstations from ETHZ - https://people.inf.ethz.ch/wirth/ProjectOberon1992.pdf https://people.inf.ethz.ch/wirth/ProjectOberon1992.pdf). The Ceres Oberon version had a number of additional features, e.g. it could use the MMU for memory protection, which the RISC5 version doesn't support.
- NonEUCitizen 6y ago
  How much memory does it require to run?
  - johndoe0815 6y ago
    The original Wirth RISC5 version runs in 1 MB RAM on an ancient Xilinx FPGA board. The RISC-V binaries are a bit larger, but still runs in 1 MB (but more is possible). A bit too large for typical block RAM sizes of affordable FPGAs, unfortunately. Some details on the port and the binary size differences can be found in the project report: https://github.com/solbjorg/oberon-riscv/blob/master/report.pdf https://github.com/solbjorg/oberon-riscv/blob/master/report....
    - snvzz 6y ago
      "block ram" (like iCE40's sysMEM) is usually very fast, fancy and dual port, which is why there's so little of it, and is typically spread across the die for reduced latency purposes. From a CPU-in-FPGA perspective, it could be used for e.g. L1 cache. Actual RAM can be slower and external to the FPGA chip. The ULX3S (which can support the minimig Amiga implementation) and the DE10-Nano (miSTer's base board) would make overkill targets for this.
      - johndoe0815 6y ago
        Of course, external RAM is an option. However, using external SDRAM increases the complexity of the hardware significantly, which takes away a bit of the elegance and simplicity of Wirth's original RISC5 FPGA system. Wirth's system used a Xilinx Spartan 3 board with 1 MB of 32 bit wide fast asynchronous SRAM (https://multicores.org/blog/small-is-beautiful.html https://multicores.org/blog/small-is-beautiful.html). Unfortunately, FPGA boards with 32 bit wide SRAM are really hard to find nowadays, especially those supported by SymbiFlow...
        snvzz 6y ago
        Definitely. SRAM is pure joy to use, but less and less common in FPGA devboards by the day.
    - cfbsoftware 6y ago
      We (CFB Software) recently managed to squeeze the full Project Oberon into 512 KB of BRAM on Digilent's Arty7-100T and NexysA7-100T boards. It is sufficient to recompile the entire system on itself.
- cxr 6y ago
  Hi, Michael. I'm familiar with Oberon and have contributed to Peter De Wachter's Norebo bootstrapping scripts. I wrote a recent comment in another thread about the use of "applicative literature" in pedagogy. <https://news.ycombinator.com/item?id=25490826 https://news.ycombinator.com/item?id=25490826> Rikke's README for this project—and many other projects related to Oberon—end up describing processes in natural language, with steps to be performed manually, e.g. to change the bootloader. This is not special to Oberon, though. The gist of my argument is that pretty much every student and professor already has a suitable environment for handling process documents that could be adapted to be also executable by a machine. Do you have any thoughts about this? Do you have any experience trying to work with anything that follows Knuth's "literate programming" paradigm (including difficulties you've encountered)? Anyway, nice work by you and your students. Wirth's RISC machine has a simplicity that others don't, which makes it good for teaching, but it makes some pragmatic choices that make it more realistic than similar attempts that result in toy computers that are a little too toy-like. It's work like this that makes for a decent transition after going from not knowing anything about a computer to hands-on understanding using a practical fantasy system like Wirth's to a full-on "industry-approved" instruction set RISC-V.
  - johndoe0815 6y ago
    Literate programming could solve some of our everyday problems, such as discrepancies between documentation and implementation (in contrast with often hard to use automatically generated documentation e.g. using JavaDoc). I'm not sure why it never caught on - perhaps most programmers rather want to work on code and not on explaining it... While not as elaborate as Knuth's WEB system, I liked the approach used by Douglas Comer in his Xinu OS books (my first OS textbook) very much. Comer's integration of explaining text sections and related code is not as tight as some of the commonly mentioned literate programming examples, but IMHO it still helps a lot to understand the system structure and the dependencies of the piece of code discusses with other parts of the system. What is great about the Comer books is that - like Oberon - they also cover more than just the OS. In the original version of the Xinu book, there was an extensive explanation of the PDP11 the system was developed on, though not on a sufficient level of detail to actually build a PDP11. While Comer doesn't include a compiler or GUI in Xinu, he extends the system in another useful direction with Xinu-based Ethernet and TCP/IP support in a second volume. The Project Oberon book includes a short chapter on networking, but this is a point where the "not-invented-here" paradigm that helps to keep the Oberon system so simple and elegant seems to break down, as real-world interfacing is essential today. The difference in complexity between the homebrew approach and TCP/IP is easy to see, however. Networking is covered in a single chapter (IIRC) in the Project Oberon book, whereas it took Comer a whole book volume to describe his TCP/IP implementation (admittedly, also including the description of a number of network protocols on top of TCP/IP).
- alexisread 6y ago
  It's great to see Oberon still being worked on! Slightly unrelated, but I was wondering if Composita was being used or looked at still (http://concurrency.ch/Content/publications/Blaeser_Component_Operating_System_PLOS_2007.pdf http://concurrency.ch/Content/publications/Blaeser_Component...)? I know that it and A2 are more complex than Oberon, but a riscV version of those would be awesome, particularly the concept of managed memory without GC.
  - butterisgood 6y ago
    A2 gets updates every few months. I am hoping to be able to work on a more “native” UX for it for MacOS rather than the xorg/X11 based one. There’s ARM support already too but I don’t think M1 works in any sense yet, so I guess I’ll have to use Bonjour2 for now. Fun stuff!
solbjorg 6y ago
Hi everyone, I've been working on this project for the last few months. I'm glad you find it interesting! I won't reiterate what my advisor has already said, but like mentioned in the README of the linked repository, if you just want to try it, you can clone the emulator here, which includes a RISC-V image: https://github.com/solbjorg/oberon-riscv-emu https://github.com/solbjorg/oberon-riscv-emu The port should also be quite easy to hack on, if you so wish. :) I'm happy to answer any questions as well.
ducktective 6y ago
Can anyone give a quick summary of what makes Oberan OS interesting? Is it an RTOS? A microkernerl? What's distinctive about it?
- wrs 6y ago
  It is a complete computing system (meaning you can do actual useful work with it) that is deliberately designed to be simple enough that a single person can understand every bit of it--processor, compiler, operating system, and applications--in a reasonable amount of time.
  - andi999 6y ago
    Can you define 'complete'? Surely this doesnt mean including applications like 'word' or 'excel' or does it? Is a GUI part of the 'complete'? I really want to know what hides behind this term.
    - johndoe0815 6y ago
      Project Oberon includes a GUI that in the Unix world would be described as using a tiling window manager. It doesn't include a word processor or a spreadsheet app - Oberon was created to build a workstation system, not an office machine - but a graphics editor is included. Other applications are available, of course, such as a tool for digital circuit design or an email tool. But one of the most important use cases for Oberon is probably software development - so one of the most important tools that is included with the system is the compiler.
    - jonjacky 6y ago
      In addition to the OS itself, the Oberon book [1] includes network, file and print servers, a mail server, a text editor, and a graphics editor capable of drawing circuit schematics. [1] https://people.inf.ethz.ch/wirth/ProjectOberon/ https://people.inf.ethz.ch/wirth/ProjectOberon/
- eterps 6y ago
  What is interesting about Oberon is that it is a complete (i.e. OS + compiler + HW) usable system that can be understood in its entirety by a single human being within one lifetime. As far as I know it's also the only system currently in existence that fullfills that promise.
based2 6y ago
https://en.wikipedia.org/wiki/Oberon_(programming_language) https://en.wikipedia.org/wiki/Oberon_(programming_language)

140 points by homarp 6y ago

Hi, this port of Niklaus Wirth's Project Oberon (http://www.projectoberon.com http://www.projectoberon.com) to RISC-V (rv32im) is the semester project of my student Rikke Solbjørg at the department of computer science at NTNU in Trondheim/Norway. The system currently runs in a version of Peter de Wachter's emulator modified to use a RISC-V CPU emulation instead of Wirth's RISC5 (now isn't that confusing? ;-)). Rikke's announcement on the Oberon mailing list: http://lists.inf.ethz.ch/pipermail/oberon/2020/015269.html http://lists.inf.ethz.ch/pipermail/oberon/2020/015269.html To answer the obvious question right away: yes, we are working on a FPGA implementation :-). Happy to answer your other questions...

pjmlp 6y ago
Just to congratulate everyone involved. Any thoughts about pursuing similar endeavours with System 3? System 3 is closer to modern systems in L&F, which could make some students feel more inspired to delve into Oberon based platforms. Just as an idea for other upcoming projects, I guess.
- johndoe0815 6y ago
  We are currently discussing a number of ideas for a followup project in addition to creating an FPGA version... I'm currently digging through the 1992/2005 edition of the Project Oberon book (for the National Semiconductor 32k-based Ceres workstations from ETHZ - https://people.inf.ethz.ch/wirth/ProjectOberon1992.pdf https://people.inf.ethz.ch/wirth/ProjectOberon1992.pdf). The Ceres Oberon version had a number of additional features, e.g. it could use the MMU for memory protection, which the RISC5 version doesn't support.
NonEUCitizen 6y ago
How much memory does it require to run?
- johndoe0815 6y ago
  The original Wirth RISC5 version runs in 1 MB RAM on an ancient Xilinx FPGA board. The RISC-V binaries are a bit larger, but still runs in 1 MB (but more is possible). A bit too large for typical block RAM sizes of affordable FPGAs, unfortunately. Some details on the port and the binary size differences can be found in the project report: https://github.com/solbjorg/oberon-riscv/blob/master/report.pdf https://github.com/solbjorg/oberon-riscv/blob/master/report....
  - snvzz 6y ago
    "block ram" (like iCE40's sysMEM) is usually very fast, fancy and dual port, which is why there's so little of it, and is typically spread across the die for reduced latency purposes. From a CPU-in-FPGA perspective, it could be used for e.g. L1 cache. Actual RAM can be slower and external to the FPGA chip. The ULX3S (which can support the minimig Amiga implementation) and the DE10-Nano (miSTer's base board) would make overkill targets for this.
    - johndoe0815 6y ago
      Of course, external RAM is an option. However, using external SDRAM increases the complexity of the hardware significantly, which takes away a bit of the elegance and simplicity of Wirth's original RISC5 FPGA system. Wirth's system used a Xilinx Spartan 3 board with 1 MB of 32 bit wide fast asynchronous SRAM (https://multicores.org/blog/small-is-beautiful.html https://multicores.org/blog/small-is-beautiful.html). Unfortunately, FPGA boards with 32 bit wide SRAM are really hard to find nowadays, especially those supported by SymbiFlow...
      - snvzz 6y ago
        Definitely. SRAM is pure joy to use, but less and less common in FPGA devboards by the day.
  - cfbsoftware 6y ago
    We (CFB Software) recently managed to squeeze the full Project Oberon into 512 KB of BRAM on Digilent's Arty7-100T and NexysA7-100T boards. It is sufficient to recompile the entire system on itself.
cxr 6y ago
Hi, Michael. I'm familiar with Oberon and have contributed to Peter De Wachter's Norebo bootstrapping scripts. I wrote a recent comment in another thread about the use of "applicative literature" in pedagogy. <https://news.ycombinator.com/item?id=25490826 https://news.ycombinator.com/item?id=25490826> Rikke's README for this project—and many other projects related to Oberon—end up describing processes in natural language, with steps to be performed manually, e.g. to change the bootloader. This is not special to Oberon, though. The gist of my argument is that pretty much every student and professor already has a suitable environment for handling process documents that could be adapted to be also executable by a machine. Do you have any thoughts about this? Do you have any experience trying to work with anything that follows Knuth's "literate programming" paradigm (including difficulties you've encountered)? Anyway, nice work by you and your students. Wirth's RISC machine has a simplicity that others don't, which makes it good for teaching, but it makes some pragmatic choices that make it more realistic than similar attempts that result in toy computers that are a little too toy-like. It's work like this that makes for a decent transition after going from not knowing anything about a computer to hands-on understanding using a practical fantasy system like Wirth's to a full-on "industry-approved" instruction set RISC-V.
- johndoe0815 6y ago
  Literate programming could solve some of our everyday problems, such as discrepancies between documentation and implementation (in contrast with often hard to use automatically generated documentation e.g. using JavaDoc). I'm not sure why it never caught on - perhaps most programmers rather want to work on code and not on explaining it... While not as elaborate as Knuth's WEB system, I liked the approach used by Douglas Comer in his Xinu OS books (my first OS textbook) very much. Comer's integration of explaining text sections and related code is not as tight as some of the commonly mentioned literate programming examples, but IMHO it still helps a lot to understand the system structure and the dependencies of the piece of code discusses with other parts of the system. What is great about the Comer books is that - like Oberon - they also cover more than just the OS. In the original version of the Xinu book, there was an extensive explanation of the PDP11 the system was developed on, though not on a sufficient level of detail to actually build a PDP11. While Comer doesn't include a compiler or GUI in Xinu, he extends the system in another useful direction with Xinu-based Ethernet and TCP/IP support in a second volume. The Project Oberon book includes a short chapter on networking, but this is a point where the "not-invented-here" paradigm that helps to keep the Oberon system so simple and elegant seems to break down, as real-world interfacing is essential today. The difference in complexity between the homebrew approach and TCP/IP is easy to see, however. Networking is covered in a single chapter (IIRC) in the Project Oberon book, whereas it took Comer a whole book volume to describe his TCP/IP implementation (admittedly, also including the description of a number of network protocols on top of TCP/IP).
alexisread 6y ago
It's great to see Oberon still being worked on! Slightly unrelated, but I was wondering if Composita was being used or looked at still (http://concurrency.ch/Content/publications/Blaeser_Component_Operating_System_PLOS_2007.pdf http://concurrency.ch/Content/publications/Blaeser_Component...)? I know that it and A2 are more complex than Oberon, but a riscV version of those would be awesome, particularly the concept of managed memory without GC.
- butterisgood 6y ago
  A2 gets updates every few months. I am hoping to be able to work on a more “native” UX for it for MacOS rather than the xorg/X11 based one. There’s ARM support already too but I don’t think M1 works in any sense yet, so I guess I’ll have to use Bonjour2 for now. Fun stuff!

solbjorg 6y ago

Hi everyone, I've been working on this project for the last few months. I'm glad you find it interesting! I won't reiterate what my advisor has already said, but like mentioned in the README of the linked repository, if you just want to try it, you can clone the emulator here, which includes a RISC-V image: https://github.com/solbjorg/oberon-riscv-emu https://github.com/solbjorg/oberon-riscv-emu The port should also be quite easy to hack on, if you so wish. :) I'm happy to answer any questions as well.

ducktective 6y ago

Can anyone give a quick summary of what makes Oberan OS interesting? Is it an RTOS? A microkernerl? What's distinctive about it?

wrs 6y ago
It is a complete computing system (meaning you can do actual useful work with it) that is deliberately designed to be simple enough that a single person can understand every bit of it--processor, compiler, operating system, and applications--in a reasonable amount of time.
- andi999 6y ago
  Can you define 'complete'? Surely this doesnt mean including applications like 'word' or 'excel' or does it? Is a GUI part of the 'complete'? I really want to know what hides behind this term.
  - johndoe0815 6y ago
    Project Oberon includes a GUI that in the Unix world would be described as using a tiling window manager. It doesn't include a word processor or a spreadsheet app - Oberon was created to build a workstation system, not an office machine - but a graphics editor is included. Other applications are available, of course, such as a tool for digital circuit design or an email tool. But one of the most important use cases for Oberon is probably software development - so one of the most important tools that is included with the system is the compiler.
  - jonjacky 6y ago
    In addition to the OS itself, the Oberon book [1] includes network, file and print servers, a mail server, a text editor, and a graphics editor capable of drawing circuit schematics. [1] https://people.inf.ethz.ch/wirth/ProjectOberon/ https://people.inf.ethz.ch/wirth/ProjectOberon/
eterps 6y ago
What is interesting about Oberon is that it is a complete (i.e. OS + compiler + HW) usable system that can be understood in its entirety by a single human being within one lifetime. As far as I know it's also the only system currently in existence that fullfills that promise.

based2 6y ago

https://en.wikipedia.org/wiki/Oberon_(programming_language) https://en.wikipedia.org/wiki/Oberon_(programming_language)