[Oberon] Wojtek's comment

Jan de Kruyf jan.de.kruyf at gmail.com
Thu Aug 27 12:25:49 CEST 2015


But Wojtek also wants to have control as to where the code is loaded.

So this morning I had a quick look in chapter 14 of the new 'Project
Oberon' and in the source files that control the boot process. At the
moment most addresses are hard wired and difficult to decipher for a novice.

so I think what might be done is: make a 'boot parameter' module, that
exports just the required variables --  with copious explanation --,  that
is imported into the regular bootloader, Kernel etc.

I think it will have 2 advantages: people with special requirements have
some insight into what is possible and what not, and will be easily helped.
And the discussions will be more to the point, and not "Oberon is this and
that, and needs to be .. and have .."
That is rather fruitless imho. You need to have a solid computer science
background and be deep into the Dijkstra / Wirth way of thinking to hack
Oberon successfully. It is a real singular beast in that respect.

At the same time of course, as it stands it works beautifully in an
embedded context, provided the bootloading process is easily accessible.

I would love to do it, but unfortunately I dont have access to an fpga
board and an fpga programming setup.

cheers,

j.





On Thu, Aug 27, 2015 at 11:26 AM, Jörg Straube <joerg.straube at iaeth.ch>
wrote:

> Wojtek
>
> You said
> 1) sometimes it is necessary to put data in fast memory (I think you mean
> BRAM)
> 2) you would like to process your ADC dara (stored in BRAM) in Oberon.
>
> Oberon works with what you call slow memory. So if you want to process
> your fast data with the slow Oberon, why not put the data in the slow
> memory in the first place?
> - Jan proposes a copy approach BRAM to SRAM and then process by Oberon
> - Chris proposes a mapped memory aaproach.
>
> To understand the Oberon memory layout have a look at figure 8.1 in
> chapter 8 of project oberon.
> You see basically that the Oberon system splits memory in four blocks
> A memory for module code
> B memory for procedure variables (called stack)
> C memory for dynamic variables allocated with NEW (called heap)
> D memory for IO (display frame buffer and IO registers)
>
> This layout is flexibly established during booting by two constants in the
> boot record, called "heapOrg" and "heapLimit".
> A starts at 0 and grows upwards
> B starts at heapOrg and grows downwards
> C starts at heapOrg and grows upward til heapLimit
> D starts at heapOrg+heapLimit
>
> Now, I think you don't like Jan's copy approach. So you could do the
> following memory map approach: Reduce "heapLimit" and map the memory range
> just below the VGA framebuffer to your BRAM (this mapping has to be done in
> Verilog)
> You can declare in Oberon a safe TYPE to your ADC data (e.g. POINTER TO
> ARRAY 256 OF BYTE) and allocate the start address of your mapped BRAM
> memory to a pointer variable.
>
> br, Jörg
>
> Am 26.08.2015 um 20:15 schrieb Jan de Kruyf <jan.de.kruyf at gmail.com>:
>
> 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
>>
>
> --
> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
> https://lists.inf.ethz.ch/mailman/listinfo/oberon
>
>
> --
> 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/20150827/519d411b/attachment.html 


More information about the Oberon mailing list