[Oberon] FPGA - Garbage Collector - GC

[Chris Burrows]

Hi Tomas,

The Garbage Collector task is called every second. However it won't do anything (including flash the LED) unless 20 actions have been performed or the used memory exceeds a certain threshold. This is controlled in the procedure Oberon.GC.

In an early version of Project Oberon that I had, the LED used to blink every second indicating that the GC was trying to do something even when it had nothing to do. I believe that this was fixed some time ago. Maybe that is what you are thinking of? 

Regards,
Chris Burrows

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


> -----Original Message-----
> From: Oberon [mailto:oberon-bounces at lists.inf.ethz.ch] On Behalf Of
> Tomas Kral
> Sent: Tuesday, 18 April 2017 1:46 AM
> To: oberon at lists.inf.ethz.ch
> Cc: Andreas Pirklbauer
> Subject: Re: [Oberon] FPGA - Garbage Collector - GC
> 
> Hi Andreas, Paul,
> 
> I only rebuilt the `FileDir.Mod' to obtain a symbol file needed as
> import to `System.Mod'.
> 
> I had backed the `System.rsc' to .Bak and deleted FileDir.{smb.rsc}
> afterwards.
> 
> It breaks GC all the same.
> 
> This is diff on `System.Mod'
> 
> pi at raspberrypi /usr/src/oberon/PO.V5.1 $ diff System.Mod.txt
> ../PO.V5.0/System.Mod.txt
> 1c1
> < MODULE System; (*JG 3.10.90 / NW 12.10.93 / NW 20.6.2016*)
> ---
> > MODULE System; (*JG 3.10.90 / NW 12.10.93 / NW 28.11.2015*)
> 89c89
> <   PROCEDURE Clear*;  (*clear Log*)
> ---
> >   PROCEDURE Clear*;  (*used to clear Log*)
> 93c93
> <       NEW(buf); Texts.OpenBuf(buf); T :=
> F.next(TextFrames.Frame).text; Texts.Delete(T, 0, T.len, buf)
> ---
> >       T := F.next(TextFrames.Frame).text; Texts.Delete(T, 0, T.len,
> > buf)
> 
> FileDir.Mod does not seem to have changed
> 
> 
> pi at raspberrypi /usr/src/oberon/PO.V5.1 $ grep MODULE
> > FileDir.Mod.txt
> MODULE FileDir;   (*NW 12.1.86 / 23.8.90 / 15.8.2013*)
> 
> Tomas
> 
> 
> On Fri, 14 Apr 2017 10:21:45 +0000
> Andreas Pirklbauer <andreas_pirklbauer at yahoo.com> wrote:
> 
> > If you have changed module FileDir, its variable size and/or its
> code
> > size will very likely have changed (even if the module interface
> > itself has not changed). Therefore, pointers from within the module
> > descriptor of FileDir, such as mod.code and mod.ptr, will no longer
> > point to "correct" starting addresses in the various sections
> inside
> > the module block of FileDir.
> >
> > So you will likely have to rebuild the inner core and load it onto
> the
> > disk's boot area, e.g., by executing the commands [1]
> >
> >  ORP.Compile Kernel.Mod FileDir.Mod Files.Mod Modules.Mod ~
> > Linker.Link Modules ~  Builder.Build Modules ~
> >
> > Note: It is the linking process that will update the module area
> > layout (i.e. the linked list of the four modules Kernel, FileDir,
> > Files and Modules), such that *after* rebooting, pointers like
> mod.ptr
> > will be correct again. With the updated mod.ptr, the GC should
> work.
> > Please make sure to also recompile the rest of the Oberon system
> > including the compiler itself *before* rebooting system
> > - just in case module keys of the inner core modules have changed.
> > Otherwise it may not come up again.
> >
> > Andreas
> >
> > [1] e.g. see
> > http://github.com/andreaspirklbauer/Oberon-building-tools
> >
> >
> >
> > ------------------------------------------
> > Tomas Kral thomas.kral at email.cz Fri Apr 14 10:49:39 CEST 2017Hi,
> >
> > Now I have figured out, recompiling OR.Compile FileDir.Mod
> System.Mod
> > ~ with most recent changes, stopped GC to collect garbage. Any
> ideas
> > what I may have done wrong? Do I have to rebuild inner core?Tomas
> 
> --
> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related
> systems https://lists.inf.ethz.ch/mailman/listinfo/oberon