[Oberon] Wojtek's comment

skulski at pas.rochester.edu skulski at pas.rochester.edu
Wed Aug 26 17:28:56 CEST 2015


> Hi Markus,
>
>> So Project Oberon _is_ and should be:
> ...
>
> Just to be clear, Project Oberon is the design of an operating system, a
> compiler, and a computer, by Niklaus Wirth and Juerg Gutknecht.
>
> Cheers,
> Paul

Paul:

  I would rephrase your statement:

 "Project Oberon WAS the design of an operating system, a compiler, and a
computer, by Niklaus Wirth and Juerg Gutknecht."

That was in 1985. Now it is 2015. How is this system useful today? We can
say "it is a museum piece of historical interest". Fine. Is this what you
and NW want? (JG seems out of the loop.)

My point is this: if the FPGA Oberon System is running in the FPGA, then
stop pretending it is running on Ceres. These days are long gone. The FPGA
is an entirely different world from the personal workstation. The first
step should be "acknowledge that FPGA is all about custom designed HW".
FPGA is not static. FPGA is constantly changing, even five times a day.
The software layer should provide convenient means of accomodating to such
changes.

I liked Chris post about SYSTEM.Get and System.Put. His solution is great.
However, it is low-level. It is similar to #define in C. We use #define a
lot in our C programs in exactly the way Chris pointed out. Is this all
that Oberon language has to offer for HW interfacing? If so then let be
it. I think that the language can do better, but if you guys object, then
what can we do?

How can the language do better? Imagine a BRAM into which we are
collecting the waveform from the ADC. (We are doing just that.) I would
like to see a high level declaration:

  VAR my_samples: ARRAY 8191 OF SHORT AT ADDRESS <address>;

Then I can use this array in the code in a type-safe way. As of today I
must use Chris' SYSTEM.Get, which is low-level, error prone, and more
difficult to maintain. So we keep claiming that Oberon is a "high level
language" despite the #define mindset which we have to use to solve an
everyday problem which is critical for the FPGA interfacing.

How about different memories, the BRAM, SRAM, SDRAM? I insist that we need
a mechanism to run critical pieces from BRAM, and less critical pieces
from slower memory. Is it going to be addressed or ignored by the Oberon
System gurus?

Another matter are those 16 registers and a single GPIO port. This was
tailored towards a particular project. Completely insufficient for any
other project.

Wojtek




More information about the Oberon mailing list