April 2017 - Oberon - mailman3.inf.ethz.ch

FPGA - Bitmaps.Mod
by Tomas Kral 19 Apr '17

19 Apr '17

Hi, I am now able to allocate memory for a bitmap with given dimensions and origin (a bounding rectangle x,y,w,h). Looking further into ETH code, I wish to continue with DisplayBlock implementation. I assume B/W coulours for the depth=1, and I set these as constants for little understanding of them ... CONST linelength = 1024 DIV 8; EZoom = 0; bytes = 1; Height = 768; ... PROCEDURE DisplayBlock*(B: Bitmap; sx, sy, w, h, dx, dy, mode: INTEGER); VAR pw, pd, src, dst, h1 : LONGINT; ... pd := B.depth; (*0; SYSTEM.GET(adr+4, SYSTEM.VAL(INTEGER, pd));*) IF pd = 1 THEN pw := B.width; (*SYSTEM.GET(adr+8, pw);*) src := B.base; (*SYSTEM.GET(adr+12, src);*) INC(src, (dy+h-1)*pw + dx); (* top left corner *) sy := Height-sy-h; (* convert to screen coordinate *) dst := Display.Base+(LSL(sy*linelength, EZoom) + sx)*bytes; IF mode = Display.invert THEN REPEAT DisplayBlock2(src, dst, w); DEC(h); DEC(src, pw); INC(dst, LSL(linelength*bytes, EZoom)) UNTIL h = 0 ELSE REPEAT DisplayBlock0(src, dst, w); DEC(h); DEC(src, pw); INC(dst, LSL(linelength*bytes, EZoom)) UNTIL h = 0 END; (*PutImage( sx, (Height-sy-h1), w, h1);*) ELSE (* depth not supported *) Display.ReplConst(1, sx, sy, w, h, mode) END; ... The code as I believe, copies a bitmap by lines from B.base address to Display.Base address, masking out bits sticking out the rectangle. Also OR-XOR inside bits depending on the mode. (I leave out clipping to a visible area for the time being) But does not work so far, does not obey x,y, also w,h. Tomas

1 0

Fw: FPGA - Bitmaps.Mod
by Andreas Pirklbauer 19 Apr '17

19 Apr '17

Yes, mainly to keep fragmentation low, but also to keep the code of the garbage collector reasonably simple. See ch. 8.2., p. 105, of the book "Project Oberon "at https://www.inf.ethz.ch/personal/wirth/ProjectOberon/PO.System.pdf <https://www.inf.ethz.ch/personal/wirth/ProjectOberon/PO.System.pdf> for a description of the properties of the heuristics used (i.e. using 4 lists instead of 1). Another benefit of the choice of values for the sizes of heap records (32, 64, 128, n*256) is that it permits the easy merging of any two contiguous elements into an element of the next list. This of course also helps keeping fragmentation low. As for “holes": In Oberon there are no holes per se in the memory area between Kernel.heapOrg and Kernel.heapLim (the “heap”) - in the sense that *each and every* block in that space is either (i) “free” (mark < 0), (ii), allocated and unmarked (mark = 0), or (iii) allocated and marked (mark > 0). By convention, for each block p, Mem[p+4] is *defined* to be the mark field, which allows the scan phase of the garbage collector to actually recognize the free blocks as such. Heap blocks can become *fragmented* though - in the sense that the both free and allocated blocks can be "spread out" throughout the heap space. ------------------------------------ Tomas Kral thomas.kral at email.cz Wed Apr 19 16:38:11 CEST 2017 Hi, Yes, I can see now. Oberon maintains distinct chains of 32,64,128, and multiple 256 byte blocks. With the idea to prevent holes and fragmentation? Many thanks Tomas On Wed, 19 Apr 2017 15:48:27 +0200 Andreas Pirklbauer <andreas_pirklbauer at yahoo.com <https://lists.inf.ethz.ch/mailman/listinfo/oberon>> wrote: > Tomas, > > The "size" of the heap record, as specified in the type descriptor, > needs to satisfy certain criteria, in order for Kernel.New to work: > a) it must include 8 bytes for the two hidden fields 'mk' and 'tag' > b) the total must be 32, 64, 128 or n*256 bytes long. > > > See module Memory.Mod on > > https://github.com/andreaspirklbauer/Oberon-generic-heap-allocation <https://github.com/andreaspirklbauer/Oberon-generic-heap-allocation> > > to see how this can be done (first three lines of procedures > Memory.New). > > It's essential (!) to set size correctly, otherwise the garbage > collector gets confused, as becomes evident when studying the code > for procedures Kernel.Mark and Kernel.Scan (which obtains the size if > a heap record by inspecting the size field in the type descriptor). > If it's not a valid size, Kernel.Scan will insert it in the "n*256" > list without the record actually being a multiple of 256. Bad! > > > [Oberon] Fw: FPGA - Bitmaps.Mod > > Tomas Kral thomas.kral at email.cz > Wed Apr 19 12:53:09 CEST 2017 > Previous message: [Oberon] Fw: FPGA - Bitmaps.Mod > Next message: [Oberon] FPGA - Naming Conventions > Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] > Hi Andreas, Joerg, I have tried both methods suggested here. (a) > without tag declaration, simply calling Kernel.New(b.base, > SYSTEM.ADR(b.size)); (b) with tag declaration and persistence > tag.size := <size of your object to be allocated>; tag.ext[0] := 0; > tag.ext[1] := 0; tag.ext[2] := 0; tag.ptr := -1; Kernel.New(b.base, > SYSTEM.ADR(tag.size)) They both seem to allocate a block of requested > size, however when GC is run, sometimes heap is inconsistent and > `System.Watch' reports strange > > Sent from my iPhone

1 0

Fw: FPGA - Bitmaps.Mod
by Andreas Pirklbauer 19 Apr '17

19 Apr '17

Tomas, The "size" of the heap record, as specified in the type descriptor, needs to satisfy certain criteria, in order for Kernel.New to work: a) it must include 8 bytes for the two hidden fields 'mk' and 'tag' b) the total must be 32, 64, 128 or n*256 bytes long. See module Memory.Mod on https://github.com/andreaspirklbauer/Oberon-generic-heap-allocation to see how this can be done (first three lines of procedures Memory.New). It's essential (!) to set size correctly, otherwise the garbage collector gets confused, as becomes evident when studying the code for procedures Kernel.Mark and Kernel.Scan (which obtains the size if a heap record by inspecting the size field in the type descriptor). If it's not a valid size, Kernel.Scan will insert it in the "n*256" list without the record actually being a multiple of 256. Bad! [Oberon] Fw: FPGA - Bitmaps.Mod Tomas Kral thomas.kral at email.cz Wed Apr 19 12:53:09 CEST 2017 Previous message: [Oberon] Fw: FPGA - Bitmaps.Mod Next message: [Oberon] FPGA - Naming Conventions Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] Hi Andreas, Joerg, I have tried both methods suggested here. (a) without tag declaration, simply calling Kernel.New(b.base, SYSTEM.ADR(b.size)); (b) with tag declaration and persistence tag.size := <size of your object to be allocated>; tag.ext[0] := 0; tag.ext[1] := 0; tag.ext[2] := 0; tag.ptr := -1; Kernel.New(b.base, SYSTEM.ADR(tag.size)) They both seem to allocate a block of requested size, however when GC is run, sometimes heap is inconsistent and `System.Watch' reports strange Sent from my iPhone

2 1

Fw: FPGA - Garbage Collector - GC
by Tomas Kral 19 Apr '17

19 Apr '17

Hi, EDIT, `System.Collect' alias GC now works. I needed to also recompile Oberon.Mod which resolved the situation. ORP.Compile FileDir.Mod Oberon.Mod SystemMod~ I also recompiled OR*.Mod with latest ORB.Mod of today. Tomas Begin forwarded message: Date: Wed, 19 Apr 2017 12:03:44 +0200 From: Tomas Kral <thomas.kral(a)email.cz> To: <oberon(a)lists.inf.ethz.ch> Subject: Re: [Oberon] FPGA - Garbage Collector - GC Hi Christopher, I see it in the code. `Oberon.Mod', problem here with my FPGA is when `System.Mod' recompiled, GC stops, even when `System.Collect' is executed manually. MODULE Oberon; (*JG 6.9.90 / 23.9.93 / 13.8.94 / NW 14.4.2013 / 22.12.2015*) ... VAR ActCnt: INTEGER; (*action count for GC*) ... PROCEDURE GC; VAR mod: Modules.Module; BEGIN IF (ActCnt <= 0) OR (Kernel.allocated >= Kernel.heapLim - Kernel.heapOrg - 10000H) THEN mod := Modules.root; LED(21H); WHILE mod # NIL DO IF mod.name[0] # 0X THEN Kernel.Mark(mod.ptr) END ; mod := mod.next END ; LED(23H); Files.RestoreList; LED(27H); Kernel.Scan; LED(20H); ActCnt := BasicCycle END END GC; ... BEGIN ActCnt := 0; CurTask := NewTask(GC, 1000); Install(CurTask); END Oberon. 1000 is polled interval in miliseconds? Tomas On Tue, 18 Apr 2017 18:25:33 +0930 Chris Burrows <chris(a)cfbsoftware.com> wrote: > 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@lists.inf.ethz.ch] On Behalf Of > > Tomas Kral > > Sent: Tuesday, 18 April 2017 1:46 AM > > To: oberon(a)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@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@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(a)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(a)lists.inf.ethz.ch mailing list for ETH Oberon and related > > systems https://lists.inf.ethz.ch/mailman/listinfo/oberon > > -- > Oberon(a)lists.inf.ethz.ch mailing list for ETH Oberon and related > systems https://lists.inf.ethz.ch/mailman/listinfo/oberon -- Oberon(a)lists.inf.ethz.ch mailing list for ETH Oberon and related systems https://lists.inf.ethz.ch/mailman/listinfo/oberon

1 0

Oberon] FPGA - Save / Restore OBERON.FS
by Tomas Kral 19 Apr '17

19 Apr '17

Hi, EDIT, at the end Reading some earlier post by Paul Read, I look for `dd' syntax to save and restore my work on uSD card. Providing uSD card is formatted as 256MB FAT + 65MB OBERON. Restore my work indexed as `1' may work like this, $ dd if=OBERON1.FS of=/dev/sdc bs=1024 seek=262145 By how about saving the work first, $ dd if=/dev/sdc of=OBERON1.FS bs=1024 skip=262145 count=??? What count should I use? `System.Watch' may give a clue, but does not seem exact. EDIT, correction I could also use a fixed value of the whole 65MB Oberon partition, but not sure if below is correct $ dd if=/dev/sdc of=OBERON1.FS bs=1024 skip=262145 count=$((65*1024)) Reading `dd' manual, allows for suffixes, $ dd if=/dev/sdc of=OBERON1.FS bs=1K skip=265M count=65M Correct? Many thanks. Tomas

2 2

Fw: FPGA - Bitmaps.Mod
by Andreas Pirklbauer 19 Apr '17

19 Apr '17

Tomas, a couple of comments on your code: 1. It is normal that you see only a single reference to procedure Kernel.New in the Oberon 2013 system, namely in procedure System.Trap - which is the system's trap handler. This is because in Oberon 2013, the operator NEW is *implemented* using the trap mechanism (in order to avoid any reference to module Kernel in the compiler). So, when the programmer writes NEW (p), the compiler generates code that first assigns the address of p to register R0 (which will then appear as variable 'a' in procedure System.Trap), and the type tag (=the address of the type descriptor) to register R1 (which will then appears as variable 'b' in procedure System.Trap), following by an unconditional branch instruction via the R12 (the module table MT), using trap number 0. So, at runtime, this generates trap 0 which in turn lands you in procedure System.Trap which then simply calls Kernel.New(a, b). 2. In your code you allocate the bitmap (VAR b: Bitmap) as a *local* variable. Make it global. This is necessary because the garbage collector *expects* the type tag to be there. The Oberon garbage collector uses a mark-scan scheme. In the mark phase (Kernel.Mark) all dynamic objects reachable from all currently loaded modules (mod.ptr in the module table) are marked. In the scan phase (Kernel.Scan), all non-reachable objects are collected. In both cases, the garbage collector dereferences p to obtain its size (p.tag points to the type descriptor, which in turn has the size of the record in its first slot). 3. Instead of just storing the *size* of the allocated object, you may in fact want to exactly replicate the *full* Oberon type descriptor, and make it globally available in your program. See chapter 8.2., page 109, of the book Project Oberon, for a detailed description of the fields of an Oberon type descriptor. But in essence, it consists of a) the size of the allocated object, b) 3 entries for the so-called extensions, and c) a list of pointer field offsets needed for the garbage collector (terminated by a sentinel value of -1). You don't really need b) and c), so you could write something like: TYPE TypeTag = RECORD size: LONGINT; ext: ARRAY 3 OF LONGINT; ptr: LONGINT; <other fields that you may want to add> END ; Then create the "type tag" by writing: VAR tag: TypeTag; and initialise it with: tag.size := <size of your object to be allocated>; tag.ext[0] := 0; tag.ext[1] := 0; tag.ext[2] := 0; tag.ptr := -1; 4. If you want your objects to be automatically collected by the Oberon garbage collector, you must make it globally reachable via a global pointer. Then they will appear in mod.ptr in the module block which are used as roots for the garbage collector. (Oberon uses all named pointer variables in existence as roots for the mark phase of the garbage collector. See Oberon.GC for the details. It simply calls Kernel.Mark(mod.ptr) for each loaded module mod. Andreas

3 6

FPGA - Naming Conventions
by Tomas Kral 19 Apr '17

19 Apr '17

Hi, Studying various ETH routines, I sometimes see Variable in capitals, sometimes lowercase. Is there a coding style to follow, e.g. globals get capitals, local lowercase, constants, etc? Many thanks Tomas

3 4

FPGA - Garbage Collector - GC
by Andreas Pirklbauer 19 Apr '17

19 Apr '17

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

3 4

Error 155 ?
by eas lab 18 Apr '17

18 Apr '17

Or was it 115? I've got a very difficult setup with SATA & IDE connected via USB extender, and can't email from the installation that tries to run Linux-ETHZ-Oberon. Vaguely I remember error <155> <can't make new symbol file>. So I made the <related dirs: System...etc.> all read/write/execute permission-enabled; but still fail, strangely after an initial OK compile. Please advise. PS. why can't <Compile> automatically System.Free * ? Because some of the involved modules my be in use ? And what about the modules that are supporting LEO ? How can the user be expected to even know which these are ? == TIA.

2 1

Fw: Fw: FPGA - Garbage Collector - GC
by Tomas Kral 14 Apr '17

14 Apr '17

Hi, 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 Begin forwarded message: Date: Fri, 14 Apr 2017 09:54:19 +0200 From: Tomas Kral <thomas.kral(a)email.cz> To: "Oberon@" <lists.inf.ethz.ch Oberon(a)lists.inf.ethz.ch> Subject: [Oberon] Fw: FPGA - Garbage Collector - GC Hi, EDIT, now GC works, I must have done something wrong when shuffling OBERON.FS around with dd here. Tomas Begin forwarded message: Date: Fri, 14 Apr 2017 09:09:02 +0200 From: Tomas Kral <thomas.kral(a)email.cz> To: "Oberon@" <lists.inf.ethz.ch Oberon(a)lists.inf.ethz.ch> Subject: [Oberon] FPGA - Garbage Collector - GC Hi, I have an interesting observation. `GC' does not seem to clean my heap any longer, after updating my system. `System.Collect' does no lit the LED(5), heap does not shrink. Anything I may have done wrong? Tomas P.S. I keep revisions in distinct directories, so I can learn from changes easily. pi@raspberrypi /usr/src/oberon $ grep MODULE.*2017 PO.V5.2/*.txt PO.V5.2/ORB.Mod.txt:MODULE ORB; (*NW 25.6.2014 / 4.4.2017 in Oberon-07*) PO.V5.2/ORG.Mod.txt:MODULE ORG; (* NW 18.4.2016 / 4.4.2017 code generator in Oberon-07 for RISC*) PO.V5.2/ORP.Mod.txt:MODULE ORP; (*N. Wirth 1.7.97 / 4.4.2017 Oberon compiler for RISC in Oberon-07*) PO.V5.2/ORS.Mod.txt:MODULE ORS; (* NW 19.9.93 / 20.3.2017 Scanner in Oberon-07*) -- Oberon(a)lists.inf.ethz.ch mailing list for ETH Oberon and related systems https://lists.inf.ethz.ch/mailman/listinfo/oberon -- Oberon(a)lists.inf.ethz.ch mailing list for ETH Oberon and related systems https://lists.inf.ethz.ch/mailman/listinfo/oberon

2 1