February 2022 - Oberon - mailman3.inf.ethz.ch

Is it really necessary to hide the list of open file descriptors from the GC?
by Andreas Pirklbauer 15 Feb '22

15 Feb '22

Thanks, this question has been a answered in the meantime. > I'm afraid the reference counter will not solve the issue, because, > firstly, one is not asked to call Files.Close, one can just leave the > file as is, and in this case the file descriptor will still need to be > collected if there are no references to it. And, secondly, > Files.Close does not actually "close" the file, but it just > flushes the buffers, and after Files.Close the file can be > still read from and written to. More calls to Files.Close > can be done later. "Close" means "close the buffers".

1 0

Re: [Oberon] Emulators
by Jörg 14 Feb '22

14 Feb '22

Wojtek > How can I proceed, in practical terms, to use your JS emulator for development? Perhaps we should start discussing, WHAT you want to change. At the moment I see three different levels of HW modifications: easy, more difficult, impossible. Basically, see an emulator as virtualization. In virtualization you have a host machine (where the emulator runs on) and a guest machine (this is the FPGA board). I ignore „containers“ at the moment Easy: if you want to extend the RISC-5 instruction set in Verilog (eg add an autoincrement instruction) the modification of the emulator is rather straight forward. I neglect the fact that you have to modify the Oberon-07 compiler to use this new instruction, because this is not important for the emulator. More difficult: if you want to add IO mapped HW (eg Ethernet or Wifi) or memory mapped HW (eg color display) to your FPGA and the host machine has an equivalent of this HW, with a little bit of effort the emulator can be modified to map the IO register commands or new memory layout to the corresponding host HW. Impossible: if you want to add HW to your FPGA and the host machine does not have an equivalent HW (eg a neutrino sensor) then it‘s impossible for the emulator to mimic the new FPGA HW. br Jörg

7 33

Re: [Oberon] Is it really necessary to hide the list of open file descriptors from the GC?
by Артур Ефимов 14 Feb '22

14 Feb '22

>> (PS: An alternative scheme would be to introduce a reference counter f.refcnt, which is increased in Files.Old and decreased in Files.Close, which would in addition remove a file descriptor from the list if the counter reaches 0. But that would make things more complicated). I'm afraid the reference counter will not solve the issue, because, firstly, one is not asked to call Files.Close, one can just leave the file as is, and in this case the file descriptor will still need to be collected if there are no references to it. And, secondly, Files.Close does not actually "close" the file, but it just flushes the buffers, and after Files.Close the file can be still read from and written to. More calls to Files.Close can be done later. "Close" means "close the buffers".

1 0

Is it really necessary to hide the list of open file descriptors from the GC?
by Andreas Pirklbauer 14 Feb '22

14 Feb '22

This question has in the meantime been answered. Answer: With the way Files is currently implemented, it *is* necessary to hide the list from the garbage collector (GC). The reason is that in the experiment described in the last post, the mark phase of the GC would of course always mark *all* elements in the list rooted in Files.root - no matter what. Because elements of this list are in fact never removed (except during garbage collection via Files.RestoreList). (PS: An alternative scheme would be to introduce a reference counter f.refcnt, which is increased in Files.Old and decreased in Files.Close, which would in addition remove a file descriptor from the list if the counter reaches 0. But that would make things more complicated).

1 0

Is it really necessary to hide the list of open file descriptors from the GC?
by Andreas Pirklbauer 14 Feb '22

14 Feb '22

Question: Is it really necessary to hide the list of open file descriptors from the GC? In the Project Oberon 2013 system, the list of open files (file descriptors) is hidden from the garbage collector (GC) by representing it by integers (addresses) instead of pointers: MODULE Files; ... TYPE FileDesc = RECORD next: INTEGER; (*list of files invisible to the GC*) … END ; VAR root: INTEGER (*File*); (*list of open files*) ... END Files. The rationale for this decision is provided in chapter 7.3 on p.92 of the book Project Oberon 2013 Edition: “All [file ] descriptors are linked together in a list anchored by the global variable root and linked by the descriptor field next. This measure may seem to solve the problem of avoiding inconsistencies smoothly. However, there exists a pitfall that is easily overlooked: All opened files would permanently remain accessible via root, and the garbage collector could never remove a file descriptor nor its associated buffers. This would be unacceptable. In order to hide this list from the garbage collector, it is represented by integers (addresses) instead of pointers”. In the original implementation of the Oberon system on Ceres computers, the garbage collector (implemented as one monolithic assembler procedure Kernel.GC) was written in such a way that the list of file descriptors (rooted in the global variable Files.root) was excluded from its mark phase. In the Project Oberon 2013 implementation, the list of files is also hidden from the garbage collector (as outlined above - by representing it by integers), but the step to rebuild the list of file descriptors such that only still referenced ones remain in the list is now *separated out* into a separate procedure RestoreList exported by module Files: MODULE Oberon; … PROCEDURE GC; (*garbage collector*) ... mod := Modules.root; WHILE mod # NIL DO IF mod.name[0] # 0X THEN Kernel.Mark(mod.ptr) END ; (*mark phase of the garbage collector*) mod := mod.next END ; Files.RestoreList; (*<------- rebuild the list of file descriptors such that it only contains still referenced (=marked) ones*) Kernel.Scan; (*scan phase of the garbage collector*) ... END GC; This raises the question whether it is actually necessary to *hide* the list of of file descriptors from the garbage collector. It seems that *so long as* it is guaranteed that procedure Files.RestoreList is called immediately after the mark phase but before the scan phase (which is the case in Oberon.GC) and that these steps are atomic (i.e. the system does not use a pre-emptive scheduler) (which is the case in the Oberon system, where tasks and procedures run to completion), there seems to be no need to do so. I have tested this by making the necessary (minor) modifications to module Files (see code excerpt below) and the system works just as fine. Any comments? Any caveats? Modified module Files: *********************** MODULE Files; (*list of files no longer hidden from the garbage collector*) ... TYPE FileDesc = RECORD next: File; (*instead of INTEGER*) … END ; VAR root: File; (*instead of INTEGER*) (*list of open files*) … PROCEDURE Old*(name: ARRAY OF CHAR): File; ... IF header # 0 THEN f := root; WHILE (f # NIL) & (f.sec[0] # header) DO f := f.next END ; (*no longer need calls to SYSTEM.VAL(..) here*) … … several other minor changes in Old and New, eliminating type casts between type File and INTEGER … PROCEDURE Init*; BEGIN root := NIL; (*instead of 0*) ... END Init; PROCEDURE RestoreList*; (*after mark phase of garbage collection*) VAR f, f0: File; (*instead of type INTEGER*) PROCEDURE mark(f: File): INTEGER; (*instead of mark(f: INTEGER)*) VAR m: INTEGER; BEGIN IF f = NIL THEN m := -1 ELSE m := SYSTEM.VAL(INTEGER, f); SYSTEM.GET(m-4, m) END ; RETURN m END mark; BEGIN (* RestoreList *) WHILE mark(root) = 0 DO root := root.next END ; f := root; WHILE f # NIL DO f0 := f; REPEAT f0 := f0.next UNTIL mark(f0) # 0; (*no more calls to GET, PUT here...*) f.next := f0; f := f0 END END RestoreList; END Files.

1 0

Python vs oberon: requirements to store 1 byte in memory
by oberon-eth＠email.cz 08 Feb '22

08 Feb '22

In a programming language python following code: sys.getsizeof('a') outputs 50 bytes of memory required for one character (!) while in oberon, procedures SIZEOF(CHAR) or Strings.Length("1") both give only 1 byte (as expected). Note the ratio 50:1. Imagine you would consume in your programm 1G of memory and it will all of sudden turn into 50G! My question: is the ratio so huge because python is an interpreter language and the python function reports some data required for an interpreter to run or is it just so big because of lack of an efficient python language implementation? On the other hand, does oberon really report correctly all the data associated with CHAR type? Isn't there any hidden memory being consumed without being reported by this oberon function? Python reports size including overhead caused by garbage collector. Is this the same case in oberon? Surely not, so what is the memory size required for oberon garbage collector to handle one CHAR? Zdenek

4 5

How to decide what will exactly be linked with oberon linker?
by oberon-eth＠email.cz 08 Feb '22

08 Feb '22

Linking object files is done in A2 with the command: Linker.Link -p=Linux64 --path=obj/ --fileName=a2 Builtins Trace Glue Unix Machine Heaps Modules Objects Kernel Strings KernelLog Streams Commands Pipes StdIO TrapWriters Reflection Traps Files UnixFiles Clock Dates Reals Diagnostics BitSets StringPool ObjectFile GenericLinker Loader BootConsole ~ What are the names on three lines after linker parameters? I understand they cannot be object names so it must be names of some groups of compiled modules. But where are these groups defined? How do I know what groups are needed to have a fully working a2 linux executable for example as in my case? Zdenek

1 1

More abstract levels.
by peter＠easthope.ca 08 Feb '22

08 Feb '22

Paul Reed paulreed at paddedcell.com Mon Feb 7 15:37:38 CET 2022 > I'm absolutely the *last* person to defend Python (!) ... Never used Python. Have used APL and J. https://en.wikipedia.org/wiki/J_(programming_language) Interesting representations of some mathematical concepts. The system is written in a language. Assembler, Oberon, C depending on the system. How is a more abstract level of problem tackled? Three possibilities apparent. (1) Design and create a library (or libraries) expressing abstract concepts in the system language. Work on a problem using the system language and appropriate library. Eg., the matrix project for ETHO. (2) Design and create a language (or languages) incorporating abstract concepts. Work on a problem using the appropriate language. Eg., Python, APL, J; in ETHO, the syntax of Oberon.Text is similar to JSON, Vinci expresses 2D graphics. (3) A combination of (1) and (2). Are (2) or (3) ever justified? Merely personal preference? Quantitative argument? Regards, ... P.L. -- mobile: +1 778 951 5147 VoIP: +1 604 670 0140 48.7693 N 123.3053 W

1 0

Re (2): Emulators / Hardware Enumerator
by peter＠easthope.ca 06 Feb '22

06 Feb '22

>From Michael Schierl in https://github.com/schierlm/OberonEmulator/blob/master/hardware-enumerator.… "Versioning ... New (major) versions may introduce incompatible changes; ... Minor versions are backwards compatible. Patch versions only add new hardware IDs and do not change any other behavior." You've given me some ideas about the mysterious ETH Oberon release numbers 2.3.6 and 2.3.7. Added them in the Glossary. https://en.wikibooks.org/wiki/Oberon#Glossary The footnote has my hypothesized interpretation. Erroneous? Stretching too far? Feedback from an ETH affiliate can help. Thanks! ... P.L. -- mobile: +1 778 951 5147 VoIP: +1 604 670 0140 48.7693 N 123.3053 W

1 0

Distribution uploaded
by thutt＠harp-project.com 05 Feb '22

05 Feb '22

For those interested, I have made the first release. You can get the whole system here: https://github.com/thutt/oberon I will be adding the compiler sources in the near future. If you want to try it out, follow the instructions in the '00README.text' file. It is known to work on Ubuntu and Raspbian. If you have trouble, please let me know. -- I have never met a beet which I like.

1 0