[Oberon] Wojtek's comment

Thu Aug 27 11:26:06 CEST 2015

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.inf.ethz.ch/pipermail/oberon/attachments/20150827/d23eeb58/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2376 bytes
Desc: not available
Url : https://lists.inf.ethz.ch/pipermail/oberon/attachments/20150827/d23eeb58/attachment.bin 