oberon-riscv VS Oberon

Compare oberon-riscv vs Oberon and see what are their differences.


Oberon RISC-V port, based on Samuel Falvo's RISC-V compiler and Peter de Wachter's Project Norebo. Part of an academic project to evaluate Project Oberon on RISC-V. (by solbjorg)


Oberon parser, code model & browser, compiler and IDE with debugger (by rochus-keller)
InfluxDB - Power Real-Time Data Analytics at Scale
Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
SaaSHub - Software Alternatives and Reviews
SaaSHub helps you find the best software and product alternatives
oberon-riscv Oberon
5 76
71 427
- -
0.0 7.4
over 3 years ago 2 months ago
Modula-2 C++
GNU General Public License v3.0 or later GNU General Public License v3.0 only
The number of mentions indicates the total number of mentions that we've tracked plus the number of user suggested alternatives.
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.


Posts with mentions or reviews of oberon-riscv. We have used some of these posts to build our list of alternatives and similar projects. The last one was on 2022-02-25.
  • Project Oberon
    7 projects | news.ycombinator.com | 25 Feb 2022
    This project is still a great example of a complete computer design, starting from Niklaus Wirth's own RISC5 CPU (not a RISC-V) and very simple peripherals over the OS, runtime/garbage collector, compiler, GUI and simple example applications.

    One problem of the original implementation is that it was based on an old Xilinx Spartan 3 development board. This is not only no longer available, but it is one of the few FPGA boards that used 32 bit wide fast (12 ns IIRC) asynchronous SRAM chips. Wirth's hardware design relies heavily on this.

    Some years ago, there was a compatible board, the OberonStation. However, it seems this is no longer manufactures: https://pcper.com/2015/12/meet-the-oberonstation-kid-friendl...

    However, some modified designs exist that implement a cache in FPGA block RAM and an SDRAM controller. These can be used one more recent FPGA boards:

    - FleaFPGA "Ohm" board with a Lattice ECP5 FPGA and 32 MB RAM (https://fleasystems.com/fleaFPGA_Ohm.html) - https://github.com/Basman74/Oberon_SDRAM

    - Radiona ulx3s, another ECP5 in an open source design (https://github.com/emard/oberon) - https://github.com/emard/oberon

    - PapilioPro using a Xilinx Spartan 6 LX, another open source PCB design (https://papilio.cc/index.php?n=Papilio.PapilioPro) - https://opencores.org/projects/oberon_sdram

    Shameless plug: my student Rikke's port of Project Oberon to RV32I (this is a real RISC-V), however, we still need to find some time to build an FPGA-based SoC. Currently, it runs in emulation: https://github.com/solbjorg/oberon-riscv

  • New Oberon+ programming language with IDE and source-level debugger (Win, Mac, Linux)
    2 projects | /r/programming | 16 Jul 2021
    You might want to have a look at https://github.com/solbjorg/oberon-riscv.
  • Ultiboberon – Oberon on bare metal Raspberry Pi
    3 projects | news.ycombinator.com | 4 Apr 2021
    Thanks for the link!

    Adapting the Project Oberon compiler code generation isn't that difficult, but the devil is in the details :). My student Rikke described some of the challenges porting Project Oberon to RISC-V in her project report (https://github.com/solbjorg/oberon-riscv/blob/master/report....).

    I assume that the most time-consuming task to get Project Oberon to run on ARM/Raspberry Pi would be to write device drivers for more complex devices, e.g. USB and Ethernet. These could be written in Oberon (which would be a considerable effort) or possibly be abstracted by using a bare-metal hypervisor that supports VirtIO device abstractions, e.g. Vmware ESXI. This way, one would only have to implement VirtIO drivers in Oberon, which is considerably less complex.

    Connecting a PS/2 keyboard and mouse instead of USB might also be an alternative, since drivers for PS/2 are far less complex: http://www.deater.net/weave/vmwprod/hardware/pi-ps2/

  • Project Oberon 2013 on RISC-V
    1 project | /r/RISCV | 21 Dec 2020
    1 project | news.ycombinator.com | 21 Dec 2020


Posts with mentions or reviews of Oberon. We have used some of these posts to build our list of alternatives and similar projects. The last one was on 2024-01-21.
  • Boehm Garbage Collector
    9 projects | news.ycombinator.com | 21 Jan 2024
    > Sure there's a small overhead to smart pointers

    Not so small, and it has the potential to significantly speed down an application when not used wisely. Here are e.g. some measurements where the programmer used C++11 and did everything with smart pointers: https://github.com/smarr/are-we-fast-yet/issues/80#issuecomm.... There was a speed down between factor 2 and 10 compared with the C++98 implementation. Also remember that smart pointers create memory leaks when used with circular references, and there is an additional memory allocation involved with each smart pointer.

    > Garbage collection has an overhead too of course

    The Boehm GC is surprisingly efficient. See e.g. these measurements: https://github.com/rochus-keller/Oberon/blob/master/testcase.... The same benchmark suite as above is compared with different versions of Mono (using the generational GC) and the C code (using Boehm GC) generated with my Oberon compiler. The latter only is 20% slower than the native C++98 version, and still twice as fast as Mono 5.

  • Niklaus Wirth, or the Importance of Being Simple
    3 projects | news.ycombinator.com | 18 Jan 2024
    Great, thanks!

    There are books online for free, e.g.


    and https://ssw.jku.at/Research/Books/Oberon2.pdf

    Oberon+ is a superset of Oberon 90 and Oberon-2. Here is more information: https://oberon-lang.github.io/, and here is the current language specification: https://github.com/oberon-lang/specification/blob/master/The.... I already had valuable feedback here on HN concerning the channel extensions. Further research brought me to the conclusion, that Oberon+ should support both, channels and also monitors, because even in Go, the sync package primitives are used twice as much as channels. Mutexes and condition variables can be emulated with channels (I tried my luck here: https://www.quora.com/How-can-we-emulate-mutexes-and-conditi...), but for efficiency reasons I think monitors should be directly supported in the language as well, even if it might collide with the goal of simplicity.

    Feel free to comment here or e.g. in https://github.com/rochus-keller/Oberon/discussions/45.

  • Tex-Oberon: Make Project Oberon Pretty Again
    3 projects | news.ycombinator.com | 6 Jan 2024
    > Does anyone know why Wirth never modernized his style?

    Readability. It's easier to read the source code with uppercase keywords. (I think Wirth once said that code is written once but read many times). See this source code - https://raw.githubusercontent.com/rochus-keller/OberonSystem... - to get an idea of this (the uppercase keywords allow you to easily scan the blocks of code). Ofcourse, one can claim that the same can be achieved better today with colour-coded keywords.

    If I remember right, the Oberon+ IDE - https://github.com/rochus-keller/Oberon - gives you an option to disable this and use lowercase keywords.

  • FreeOberon cross-platform Oberon language IDD
    3 projects | news.ycombinator.com | 12 Nov 2023
  • Project Oberon (New Edition 2013)
    2 projects | news.ycombinator.com | 14 Sep 2023
    > gain a deep understanding of it .. generate smaller subsets of the system

    You can use the OberonViewer for this purpose with the original source code, or the Oberon IDE with a version of the Project Oberon System which runs with SDL on all platforms, see https://github.com/rochus-keller/oberon/#binary-versions and https://github.com/rochus-keller/OberonSystem/tree/FFI

  • KolibriOS on Single Floppy Disk
    2 projects | news.ycombinator.com | 4 Sep 2023
    > Regardless, which one is more likely to be ported to a different architecture in the future?

    Not sure I understand the question. I'm talking about CPU architectures. The current implementation is in x86 assembler. So if you want to run it on AMD64 or ARM, then you have to replace all assembler files, in the present case probable the full source code.

    > what are the comparative performance benchmarks of the low-level language versus the high-level language?

    I don't have any measurements. But consider that many operating systems are implemented in C (e.g. Linux) with only isolated parts in assembler, so it is easier to port to other architectures. Linux apparently is fast enough and available for nearly every CPU. Oberon in contrast to C is garbage collected, which also affects performance. I have measurements comparing the same benchmark suite implemented in C++ and in Oberon, where the former is about 22% faster (see https://github.com/rochus-keller/Oberon/blob/master/testcase...).

  • Why Use Pascal?
    5 projects | news.ycombinator.com | 8 Jul 2023
  • C or LLVM for a fast backend?
    3 projects | /r/ProgrammingLanguages | 2 Jun 2023
    I actually had a similar problem some years ago and finally moved away from LLVM because of complexity, continuous research effort and performance. My current Oberon+ implementation works like this: the CIL code generator together with Mono is used during development, integrated with the IDE, using the debugging features integrated in Mono; to deploy the application and to gain another factor 2 of performance C99 instead of CIL can be generated and compiled with any compatible toolchain. Here are some performance measurements: https://github.com/rochus-keller/Oberon/blob/master/testcases/Are-we-fast-yet/Are-we-fast-yet_results_linux.pdf. Compiling to CIL is very fast and the time Mono needs to compile and run is barely noticable.
  • Do transpilers just use a lot of string manipulation and concatenation to output the target language?
    4 projects | /r/ProgrammingLanguages | 27 May 2023
  • Native AOT Overview
    8 projects | news.ycombinator.com | 26 May 2023
    > annoying aspects was requiring the .NET runtime ... OpenJDK is a blessed implementation in a way that Mono never was

    Which is unjustified, because Mono CLR is just a single executable less than 5 MB which you can download and run without a complicated installation process (see e.g. https://github.com/rochus-keller/Oberon/#binary-versions ). AOT compilation on the other hand is a huge and complex installation depending on a lot of stuff including LLVM, and the resulting executables are not really smaller than the CLR + mscorlib + app.

What are some alternatives?

When comparing oberon-riscv and Oberon you can also consider the following projects:

mirage - MirageOS is a library operating system that constructs unikernels

MoarVM - A VM with adaptive optimization and JIT compilation, built for Rakudo