Our great sponsors
-
TheOberonCompanionCD
This is the original contents of the CD to the book "The Oberon Companion" (vdf, 1998)
-
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.
"the core parts of KolibriOS (kernel and drivers) are written entirely in FASM assembly language", that's amazing. Porting it to another architecture is likely a full rewrite.
In comparison, the Oberon System 3 (see e.g. https://web.archive.org/web/20120630140329/http://www.ethobe...), which was written in the Oberon high-level language, also had a graphical user interface and network support and required 4MB RAM and 2MB disk space (see https://github.com/OberonSystem3/TheOberonCompanionCD/blob/m...).
> 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...).