[Oberon] Static variable overflow (bug?)

[Jörg]

Yes, the compiler. And a few other things.

 

With the command “System.Watch” you can see, how much memory you still have available.

br

Jörg

 

Von: Oberon <oberon-bounces at lists.inf.ethz.ch> im Auftrag von Hans Klaver <hklaver at dds.nl>
Antworten an: ETH Oberon and related systems <oberon at lists.inf.ethz.ch>
Datum: Montag, 24. Februar 2020 um 15:25
An: ETH Oberon and related systems <oberon at lists.inf.ethz.ch>
Betreff: Re: [Oberon] Static variable overflow (bug?)

 

Andrea and Jörg,

 

Thanks a lot for your clear explanations! Now I understand much more about the different ways to allocate memory in the PO compiler. 

 

Still, I'm wondering about the difference between the two disk images provided by Peter de Wachter:

With Oberon-2016-08-02.dsk on a freshly opened Oberon System MyViewer does not show the menu problem, even if it defines max = 65768, and if there are several viewers open gives a run time message "Call error: MyViewer insufficient space" and refuses to open the viewer; whereas Oberon-2019-01-21.dsk shows the menu problem with max = 16367. 

 

What causes this difference? Did the compiler change that much in the meantime?

 

Cheers,

 

Hans

 

 

Jörg <joerg.straube at iaeth.ch> wrote:


The current compiler generates wrong code for global variables and/or strings exceeding 64KB. And even worse, it doesn‘t alert you, you passed this 64 KB limit.

With max =16367 your bitmap occupies 65468 bytes. The compiler puts the strings after the global data. So, the strings now lay beyond the 64KB limit. As the code to access the strings is wrong, you will never be able to access your strings anymore.

There are two ways: wait for a corrected compiler that doesn’t have this limit anymore. Or allocate your bitmap on the heap as Andreas proposed.

BTW: ProjectOberon‘s screen is 1024x768. To allocate a bitmap of that size on the heap, max = 24576 (iso 32768 as in Reiser‘s book) would be sufficient.




Andreas Pirklbauer <andreas_pirklbauer at yahoo.com> wrote: 





CONST 
 max = 16377;  (* If max >= 16367 the frame name disappears; If max >= 16377 the whole menu line disappears! *)
 menu = "System.Close System.Copy System.Grow”; 

VAR bitmap: ARRAY max OF SET;  (* with this variable present the menu may remain empty! *)


The issue is that Project Oberon 2013 does not know how to handle data accesses at offsets > 64KB from the module’s static base. A module block in memory consists of 3 sections (see ch. 6, p. 79 of the book Project Oberon 2013)
- data  (which in turn contains type descriptors, the variable space and strings - in that order!)
- code
- meta

If you declare a global bitmap variable which takes up more than 64KB, the module loader will actually allocate the appropriate amount of variable space (even if it is >64KB) and even place your string “menu” just after that (strings are treated like pre-initialized, immutable global variables).

But one cannot access the string, as it is beyond the 64KB boundary. This is an undocumented limitation of PO 2013 and the Oberon-07 compiler (regrettably) does not warn you about it, when compiling a program.

This limitation has to do with the way global variables are accessed. It typically involves loading the static base of the module via a LD instruction + adding an offset via an ADD instruction. However, an ADD instruction which has an offset field of only 16 bits = 64KB, this is where the limitation comes from. There are ways around this, but it’s just not implemented in Project Oberon 2013.

=> If you remove the bitmap variable declaration or make it so small that the sum of the bitmap + your string is <64KB, your program should work.

To use a bitmap of more than 64KB you can allocate in the heap, as in

  MODULE M;
    CONST max = 16384;
    TYPE BitMap = POINTER TO BitMapDesc;
      BitMapDesc = RECORD bits: ARRAY max OF SET END ;

    VAR bitmap: BitMap;

    PROCEDURE AllocateBitmap*;
    BEGIN NEW(bitmap)
    END AllocateBitmap;
  END M.

  ORP.Compile M.Mod/s ~
  M.AllocateBitmap

But remember, even the heap space in Project Oberon 2013 is limited to a few hundred KB only.


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

 

-- 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: <http://lists.inf.ethz.ch/pipermail/oberon/attachments/20200224/7221f1a3/attachment.html>