Great project - love to see more alternative systems.
It should be noted that this is a port (or, rather a rewrite in Pascal) of Peter de Wachter's RISC5 emulator to a bare-metal Raspberry Pi environment, not a native Oberon system running on bare-metal ARM (i.e. there is no ARM compiler backend and all binaries are compiled for RISC5 and run in emulation).
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.
Thank you, that is helpful background. Running Oberon code this way is akin to running Python code on Micropython on bare metal. But probably faster.
Even running in an emulator on bare metal is more fun than anything coddled in a massive OS. The threshold of fun is where you get to schedule and vector your own interrupts.
At some point you will hunger for the actual native code experience, but the difference turns out to be pretty abstract unless you are counting clock cycles. The software that landed the Apollo Lunar Excursion Module on the moon was mostly coded to an emulator.
I recall reading somewhere that was the original idea of P-Code, Wirth never planned to use it as basis for Pascal emulators, rather as a tool for bootstraping compilers, but then Pascal USCD took off.
Yes I do keep one, but most likely you won't find there what looking for.
Most of my stuff have learned has been over reading papers, magazines and still being around since the late 70's, most of which you won't find on my blog.
In any case, my nickname alongside Oberon will get you there.
> "Ultibo core is an embedded or bare metal development environment for Raspberry Pi. It is not an operating system but provides many of the same services as an OS, things like memory management, networking, filesystems and threading plus much more."
Is there a name or term for a library that provides OS Services in such a manner that the final application does not need an OS to run?
Such a technique strikes me as a great way to eliminate the huge space of possible system exploits. We all have clients with dedicated systems devoted to running specific applications; why not make those system truly dedicated with no OS, just the dedicated application supplying all OS needs within itself?
The first microcontrollers I ever messed with were MC6811 based boards like the HandyBoard. I never thought of it before, but I think they were unikernel.
Basically that is how many computers used to work in the old days, and also what is known as bare metal programming, where the language runtime takes the role of a very thin OS.
> Is there a name or term for a library that provides OS Services in such a manner
Yes, it's called an OS. Absurd reductionist cultivating of a zoo of hyper-focused jargon to create the illusion of exclusionary expertise does not change that fact.
Quote: "It is not an operating system but provides many of the same services as an OS, things like memory management, networking, filesystems and threading plus much more."
Well, if it looks like a duck and walks like a duck, it is a duck. Let's not beat the bush here, it is an operating system.
Also this misses a "2016" in title, since that was the last time the GitHub repository was touched by developer.
It should be noted that this is a port (or, rather a rewrite in Pascal) of Peter de Wachter's RISC5 emulator to a bare-metal Raspberry Pi environment, not a native Oberon system running on bare-metal ARM (i.e. there is no ARM compiler backend and all binaries are compiled for RISC5 and run in emulation).