[Oberon] Wojtek's comment

Peter Matthias PeterMatthias at web.de
Fri Aug 28 15:48:25 CEST 2015



Am 28.08.2015 um 13:29 schrieb Jan de Kruyf:
> 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.

Oberon not only has one linker, it has two linker. a static one for the 
inner core and a dynamic one for the rest.

> 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"

Yes, no clear boundary between Kernel, OS, Libraries and Application.

> 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.

At least too many per user ;-)

> 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.

System parts in application space seems a bad idea to me.

> 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.

Not the only one...

> 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.

I don't see how this could work.

> 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.

For variables of basic types this might work.

> 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!

As soon as you have RECORDS or ARRAYS the compiler has to be involved. 
The addresses would have to be some kind of pointers. Records have a tag 
the compiler has to be aware of. Array have size information as first 
data...

> 5. the idea is easily ported to any embedded processor.

This has to be proved.

> 6. it is elegant and minimalistic, with maximum benefit.

I don't see any benefit at all. Hardware programming is inherently 
unsafe. Adding type safety to its registers just adds nothing. Native 
Oberon shows that hardware driver easily can be well abstracted and 
written in a module.

Regards,
	Peter

>
> Enjoy,
>
> j.
>
>
>
> On Thu, Aug 27, 2015 at 4:52 PM, <skulski at pas.rochester.edu
> <mailto: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 <mailto: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
>



More information about the Oberon mailing list