[Oberon] Wojtek's comment

[Jan de Kruyf]

skulski,
we dont 'object'.
But we can do without a version for every toy about town, on good
scientific grounds. Oberon tries to be a safe language. meaning that any
person can use it, without having to be afraid to fall into some silly
trap. And it tries to be a minimalistic language that is very easy to learn
for a novice.

Further I am sure that by using ADR(v) and MOVE(s, d, n) and or PUT(a, x)
you can set up an array of variables, obtain the address and dump your data
into it.
That is the way it has been done from day one in most languages. In fact if
you would bother to study a few low level file systems in a few languages
you will find out that the Oberon way of doing things is by far the easiest
to understand for a novice.
And you are free to set up a higher level facility for your needs, in a
module that you call as you need it. I am sure the execution time will be
equal to any higher level construct in the language.
This is the Oberon way of doing things. It works and it is fully
transparent. You can know what your code is doing at a hardware level.
There are no hidden layers build in by the compiler to obfuscate your
understanding of the process.

To do it any other way would mean that we have to revise the language just
about every 6 months as and when new hardware gadgets are incorporated in
micro-controllers / fpga's. And the book would not be 17 pages but 1700
pages long.
This is the trade off the designer consciously chose. Also in the 80's many
keywords could have been added to the language ( I know, I was around then)
to make it "easier" and more "modern".

What you want is something like python (but you would not like the
execution speed)  where anybody can add features to the runtime.
Perhaps, since Oberon does not guarantee a real time response, you might
also like to look at a few other languages with a different ideology.
C or if you are brave you might try Ada, there you can do an address
overlay or assign a variable to an address. But in order to support things
like that in a safe way, the language has grown horribly complex.
So personally I rather like the Oberon minimalistic way. It has nothing to
do with "old-fashioned", but everything with "elegant".

j.

. . . . . .
Since the Romans have taught us "Simplex Veri Sigillum" —that is:
simplicity is the hallmark of truth— we should know better, but complexity
continues to have a morbid attraction. When you give for an academic
audience a lecture that is crystal clear from alpha to omega, your audience
feels cheated and leaves the lecture hall commenting to each other: "That
was rather trivial, wasn't it?" The sore truth is that complexity sells
better. (It is not only the computer industry that has discovered that.)
And it is even more diabolical in that we even use the complexity of our
own constructs to impress ourselves. I have often been impressed by the
cleverness of my own first solutions; invariably the joy of the subsequent
discovery how to streamline the argument was tempered by a feeling of
regret that my cleverness was unnecessary after all. It is a genuine
sacrifice to part from one's ingenuities, no matter how contorted, Also,
many a programmer derives a major part of his professional excitement from
not quite understanding what he is doing, from the daring risks he takes
and from the struggle to find the bugs he should not have introduced in the
first place.
https://www.cs.utexas.edu/~EWD/transcriptions/EWD08xx/EWD898.html


On Wed, Aug 26, 2015 at 5:28 PM, <skulski at pas.rochester.edu> wrote:

> > 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
>
>
> --
> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
> https://lists.inf.ethz.ch/mailman/listinfo/oberon
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.inf.ethz.ch/pipermail/oberon/attachments/20150826/467d49ee/attachment.html