[Oberon] V4 Native?

Skulski, Wojciech skulski at pas.rochester.edu
Sat Jul 29 15:57:45 CEST 2017

> Claudio Nieder [private at claudio.ch] wrote:

> www.ethoberon.ethz.ch/hcl.html

> This list illustrates well the advantage of NOT going native. 
> Having another layer, e.g. Linux, below Oberon you can profit 
> of the work of a lot of people which are not even interested 
> in Oberon to provide you with the necessary driver to access 
> whatever off the shelf Hardware you want to use.

This is true. But there is a price to pay, if Oberon is running on top of
a Linux kernel or Windows in "user space". This becomes known as soon as 
you actually access that necessary hardware. If the HW is slow, then 
everything looks fine. If the HW is fast or time critical, then you will start 
seeing the underlying scheduler, the overhead of switching to the kernel mode 
via system calls, and competition from other processes which you 
do not really control. You will see the effect of the Reiser Law 
in that underlying part of your system. So, even though the 
Oberon is still simple and predictable, the entire system is not, because the 
complexity resides in the operating system running below.

Here is an example. I am currently struggling with all this in my designs. 
I am running a gigahertz ARM accessing a memory-mapped device 
(an FPGA) via a memory interface. The interface is nominally quite fast 
(close to a hundred MB/s or so), but as of now I am reaching about 
1 MB/s due to an overhead from the underlying Linux. And this is plain 
and very simple C utility running in user space. The overhead is to be blamed 
on the system architecture, system calls, and the competition from everything 
that Linux is running in addition to my utility. 

> Going native makes sense when you are really interested and want to spend 
> the necessary time to learn the working and build yourself 
> all the glue needed to control the specific HW you have. 
> Even more so, when you build your HW yourself as Wirth did with Ceres 
> and now the RISC5 FPGA implementation.

I can appreciate effort which Chris puts into RISC5.


More information about the Oberon mailing list