4 ms·

KolibriOS on Single Floppy Disk

4 points by modinfo 3y ago

Rochus 3y ago
"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.ethoberon.ethz.ch/native/WebScreen.html 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/main/Native/StdAlone/INSTALL.TXT https://github.com/OberonSystem3/TheOberonCompanionCD/blob/m...).
- fuzzfactor 3y ago
  >Porting it to another architecture is likely a full rewrite. Regardless, which one is more likely to be ported to a different architecture in the future? And disregarding similar resource requirements, what are the comparative performance benchmarks of the low-level language versus the high-level language?
  - Rochus 3y ago
    > 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/testcases/Are-we-fast-yet/Are-we-fast-yet_results_linux.pdf https://github.com/rochus-keller/Oberon/blob/master/testcase...).

4 points by modinfo 3y ago

"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.ethoberon.ethz.ch/native/WebScreen.html 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/main/Native/StdAlone/INSTALL.TXT https://github.com/OberonSystem3/TheOberonCompanionCD/blob/m...).

fuzzfactor 3y ago
>Porting it to another architecture is likely a full rewrite. Regardless, which one is more likely to be ported to a different architecture in the future? And disregarding similar resource requirements, what are the comparative performance benchmarks of the low-level language versus the high-level language?
- Rochus 3y ago
  > 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/testcases/Are-we-fast-yet/Are-we-fast-yet_results_linux.pdf https://github.com/rochus-keller/Oberon/blob/master/testcase...).