[Oberon] NAstrobe for RISC5 on Pepino

[Chris Burrows]

> -----Original Message-----
> From: Oberon [mailto:oberon-bounces at lists.inf.ethz.ch] On Behalf Of
> Skulski, Wojciech
> Sent: Friday, 3 August 2018 12:54 AM
> To: ETH Oberon and related systems
> Subject: Re: [Oberon] NAstrobe for RISC5 on Pepino
> 
> Use case 3.
> Imagine using NOR flash with QSPI interface for execution-in-place
> (XIP). It is an interesting option, because modern QSPI flash is fast
> indeed. But it is read-only. So the code and the read-only variables
> can be mapped to NOR flash, while the read/write variables must be
> assigned to RAM.
> 
> A feasible hardware can be built with QSPI flash for the code and RO
> variables, and without any external RAM, if the BRAM is sufficient
> for the RW variables. Such a board could be very small in size and
> very inexpensive.
> 
> In order for this to work, there needs to be a facility to map
> variables, arrays, and also the executable code to predefined
> addresses. 

This is the way Astrobe Oberon runs on the Cortex-M devices. All of the code
is in flash ROM and all of the global variables, local variables (stack) and
dynamic variables are in RAM. Some of the peripherals (e.g. USB) have their
own reserved areas of RAM but that is managed by the hardware. The three
areas of RAM (one fixed in size and the other two varying) can be managed
very efficiently. The global space (which is known at runtime) is allocated
at the top of RAM when the program starts. The heap then grows from the
bottom end upwards and the stack grows downwards from the bottom of the
global space. There's only ever a problem when they meet somewhere in the
middle. 

Some of the Cortex-M devices have a separate area of RAM which is
non-contiguous so we give the users the option of locating the heap there
instead which frees up more space to be used on the stack. 

What makes it even more simple is that there is only ever one application. 

Applications running on Project Oberon are a different story altogether. The
whole system is ingenious, much more efficient and significantly less of a
memory hog than some other operating systems. Here are some of its features:

* There can be several applications ready to run loaded in memory at the
same time. 
* When an application is started it only needs to load the modules from the
SD card that are not already in memory. 
* There is only ever one copy of a module in memory at one time which makes
for extremely efficient use of RAM.
* The values of global variables in shared modules are visible to every
applications. 
* Dynamic memory can be automatically reclaimed when it is no longer used. 
* The code space used by modules can be freed if no application is still
referencing them
etc. etc. 

Much of this is handled automatically by the operating system. It is
extremely convenient, reliable and idiot-proof. You would need to gain a
thorough understanding of how this is all implemented if you want to
'enhance' it in any way without risking breaking it,

Regards,
Chris Burrows

CFB Software
http://www.cfbsoftware.com/RISC5