[Oberon] Wojtek's comment

[Jörg Straube]

Jan

The 4 modules buildng the "inner core" (Kernel, Files. FileDir and Modules) are linked and loaded from a fixed location on disk (bootsectors) to the lowest memory by the bootloader.
The bootloader then jumps to the Init routines of the inner core and there all other modules are dynamically loaded with the statement Load("Oberon") in module Modules

The memory layout (heapOrg and heapLimit) are also part of the bootsectors.

Principally, the whole system can run from BRAM.
Map the memory starting from 0 to your BRAM. The current module Oberon imports a lot of modules and establishes the GUI. So for enbedded systems where you don't need the GUI (although this is one of the strongest points to dynamically load modules, test them, correct and compile them, unlaod them and load the new version again) you have to change the existing module "Oberon" anyhow.

I have to think of the implications of having two different kind of memory as you would most probably need two stack pointers. 

br Jörg

> Am 28.08.2015 um 13:t29 schrieb Jan de Kruyf <jan.de.kruyf at gmail.com>:
> 
> Hallo,
> I like to get some comment here from the people in the know!
> 
> On the matter of memory mapping things in any Oberon.
> 
> As an introduction: 
> 1. Oberon has not got a linker (except in some cases Chris mentioned). Linking is done dynamically as and when the system decides a module is needed.
> 2. In Oberon there is no clear boundary between "runtime library", "operating system" and "user-land" like we have in linux or any other os. On the contrary the boundary is very fluid. What I called the runtime just now, might just as well be called a more permanent part of user-land (in the sense that is is almost always loaded) The only real distinction is "boot-loader" and "applications"
> 3. Where in the past the compiler was attacked, it was to prove a radically new concept: Oberon-V4, Xoberon, Component Pascal and Active Oberon come to mind. In the greater scheme of things Oberon 7 is merely a revision of Oberon 2.
> So in other words: the number of language dialects have been kept to a minimum, although there are perhaps too many already.
> 
> Although I might partly agree that to be able to assign an address attribute to a variable sounds like a nifty idea, I am not in favour of it. Because then we should rather look more generally into the matter of assigning attributes to things. And that will open up a huge can of worms. In fact such a huge can, that I advise to use Ada instead, where you have such a need.
> Secondly my experience is that it needs solid planning and strict discipline to keep all the address attributes together in one place, so the whole circus stays readable and maintainable.
> 
> This leaves us with the boot-loader / application space to reach our goal, since using a linker is a bit 'uncool', to be prevented where we do not need it.
> That is why I proposed earlier to use a system-constants Module. It is neither here nor there if we create such a thing or not. The language stays the same and is readable and the program stays maintainable by anybody conversant with the art. It is just another part of "application space". And the idea is widely portable.
> 
> In the same vein I like to propose that we have a careful look at the way modules get loaded. 
> 
> Say we have a Module with only exportable variables that occupy a contiguous range in memory (like for memory mapped io), in fact for a different range of memory we might simply create another Module.
> So we create pairs:
> Range of memory -- Module,
> Range of memory -- Module,
> etc.
> Now the only difficulty left is to actually get them loaded with their variables overlapping the range of memory we had in mind when we created the Module.
> 
> At this moment in time, having had a very brief look at the system software, I believe this is not too difficult to arrange.
> Perhaps the system-constants Module might contain the table of pairs mentioned above, or we might find another acceptable way.
> 
> This idea might in fact also take care of hardware system flags under software control, like a cpu speed flag.
> All you need to do is import the relevant module, and there you have your hardware-locked-in-place variables ready to be manipulated.
> 
> Advantages over most other schemes I know of:
> 
> 1. We still don't need a linker. In fact the linker script, that great source of unknown darkness,  is replaced by the system-constants Module; and then only partly.
> 
> 2. All address attributes to variables are of necessity  kept in one place. Any hardware locked variable is easily recognized in the program, since it is imported from one of these special modules. 
> 
> 3. a set of programs without hardware locked variables will still function as it always has, even if a system is modified to accept hardware-locked-variable modules. It is completely transparent. 
> 
> 4. The compiler is left alone, no need to break things that work!
> 
> 5. the idea is easily ported to any embedded processor.
> 
> 6. it is elegant and minimalistic, with maximum benefit.
> 
> 
> Enjoy,
> 
> j.
> 
> 
> 
>> On Thu, Aug 27, 2015 at 4:52 PM, <skulski at pas.rochester.edu> wrote:
>> Juerg:
>> > 1) sometimes it is necessary to put data in fast memory
>> > (I think you mean BRAM)
>> > 2) you would like to process your ADC data (stored in BRAM)
>> >     in Oberon.
>> 
>> Let me make it clear for those in the audience who are new to the FPGA
>> design. BRAM is a dual port memory. It has many uses which I can discuss
>> if there is interest. Here we are talking of data acquisition (DAQ) with a
>> few nanoseconds per data sample. A typical high performance DAQ design
>> uses BRAM port A to write data from the converter, and it uses port B to
>> access the data when the DAQ stops. (Think of a digital oscilloscope.) The
>> data needs to be accessed in situ. Copying it to slow memory would render
>> the instrument slow and unusable.
>> 
>> The bottom line: there is need to map a BRAM to the processor's memory
>> space. This has been discussed by Jan (thank you, Jan!). His prescription
>> is low level. OK, let be it. But let me make it clear that moving the data
>> is not permitted. Accessing the data without moving is necessary.
>> 
>> Furthermore, the code which implements the data processing needs to be
>> executed from BRAM as well. (It will be a different block of BRAM.) I
>> think that RISC5 can run at some 100+ MHz when it executes from BRAM. We
>> have looked at the RISC5 Verilog and we see that it needs to be reworked
>> in this direction. Hopefully it can reach 100+ MHz from BRAM. Then the
>> slow code can be put into off-chip SRAM and we can use the stall signal to
>> slow the processor down to match the SRAM.
>> 
>> >From this discussion it follows that we need to map both the variables and
>> the code to particular addresses. The mechanism for doing this needs to be
>> specified somehow. Of course we can take the Oberon System and hack it,
>> but this would be ugly. I am hoping that a sort of agreed-upon approach
>> will emerge from this discussion.
>> 
>> 
>> > 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?
>> 
>> Performance will be unacceptable. In our design we will use "ping-pong
>> buffers" implemented in BRAM. When one BRAM buffer acquires the data, the
>> previous data from the other buffer is being processed in situ.
>> 
>> > - Jan proposes a copy approach BRAM to SRAM
>> 
>> Unacceptable for the performance reasons.
>> 
>> > and then process by Oberon - Chris proposes a mapped memory aaproach.
>> 
>> This is the way.
>> 
>> 
>> > 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)
>> 
>> We need to statically allocate variables to HW addresses. Would be really
>> nice to have this facility for both the scalar variables (aka "registers")
>> and arrays which will be overlaid over BRAM blocks.
>> 
>> Furthermore, we need the facility to specify that certain code is executed
>> from BRAM to gain performance. This can be specified per module to keep
>> with the modular spirit of the language. A finer granularity would be
>> complicated and not necessary.
>> 
>> Here we are talking of a factor 5x in performance between BRAM and
>> external SRAM. This is not a small optimization. It is quite crucial.
>> 
>> At present there is the single MODULE* which is locked into BRAM, so we
>> are almost there. I hope that we can use the MODULE* as the "system
>> library" of sorts, where the performance-critical code will be put and
>> called by the "slow code" that lives in SRAM. However, it is a hack. It
>> would be really nice if the memory allocation could be specified for
>> regular modules as well, on a per-module basis.
>> 
>> 
>> > 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.
>> 
>> I think this is all good. It is a bit of a hack put on top the classic
>> design, but it looks workable to me. Thank you for the suggestions.
>> 
>> Jan wrote:
>> 
>> >> But we can do without a version for every toy about town
>> 
>> I am discussing features that may seem exotic to a computer scientist.
>> These "toys" are not toys for an electrical engineer working with FPGAs.
>> They are in fact fundamental in the realm of FPGA design. My point is that
>> the FPGA Oberon System is running in the FPGA. It would be good to know
>> how the FPGA Oberon can help using the FPGA to the fullest extent. If it
>> does  then it will become a much more attractive tool.
>> 
>> Thank you,
>> 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/20150828/bfba3a78/attachment-0001.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/20150828/bfba3a78/attachment-0001.bin