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

Wanted: Oberon Syntax in TextMate, Sublime Text or Atom Grammar
by Treutwein Bernhard 01 Jan '22

01 Jan '22

Does somebody have grammars for Oberon / Oberon-2 / Component Pascal / Active Oberon as grammar for TextMate / Sublime Text / Atom Background: Github wrongly classifies Oberon / Oberon-2 / Component Pascal / Active Oberon as Modula-2. I opened quite some tiome ago an issue in the github/linguist project (https://github.com/github/linguist/issues/3888) and they don't accept EBNF grammars. -- Bernhard Treutwein

6 9

Debugging FPGA oberon via serial line?
by Michael Schierl 29 May '20

29 May '20

Hello, while I was adding UTF-8 support to Fonts and Texts (and almost rewriting Fonts so that a font can be loaded partially and not all glyphs at once), I noticed that debugging such a system can be cumbersome (as you cannot read the TRAP output any more, as well as you have to reset the system to a previous state to be able to fix your mistakes if the screen is too garbled to be useful, or if the system TRAPs during boot). By the way, here is Oberon running in the browser with UTF-8 support for Texts (and Tahoma font): http://schierlm.github.io/OberonEmulator/emu.html?image=UnicodeDiskImage >From other (older) systems, I know it is possible to debug them via serial line, so I was thinking how much the FPGA oberon system needs to be changed (hardware side/software side) to accommodate this. RS232 is supported, so you could use one FPGA system (or emulator) to debug the other one. And I was wondering if anybody already tried doing something like this. I know that Colby Russell worked on debug support in the emulator, but no idea about how far he got. A minimal feature set to be useful (in my opinion) would be - Read and write memory and disk via serial port while the system is running/idle (already possible today via ORC / PCLink) - Set and remove software breakpoints while the system is running/idle - When software breakpoint or trap is hit, save processor state and allow debugging via serial port (-> suspended) - Read and write registers and memory while the system is suspended - Set and remove software breakpoints while the system is suspended - Continue execution when the system is suspended More advanced features would be single stepping (can be emulated by having a look at the instruction and setting software breakpoints at all following locations), or memory breakpoints. Also to be able to enter the debugger by pressing a hardware button on the FPGA (similar to the current reset functionality, but not resetting). And of course symbolic debugging :) Software breakpoints should be easy, just replace instruction by BL to a fixed address. Restore the instruction before returning. For catching TRAPs, overwrite the TRAP address. Saving processor state might be tricky, especially SYSTEM.H and the flags, and maybe you have problems since you need at least one spare register to be able to save the registers to a fixed location in memory. You will also need to switch stack to a second stack before the stack is accessed by the code. Probably solvable by using a special compiler that leaves a register or two unused. Restoring SYSTEM.H and Flags is also not supported (except by searching for instructions that will result in the desired flags or results). Also the question is whether returning to the code will not destroy some flags again. And you need to make sure not to set breakpoints or break at points where a BL has happened but the link register has not been saved yet. So (similar to interrupt) probably some hardware support is needed for this. Entering the debugger by button also needs hardware support (since the current Reset button forgets the PC and some other state). Once in suspend mode, it might be hard to avoid allocating memory, since you cannot run the GC which might collect objects that are still used by the suspended program. But that should be feasible if the functions are basic enough to work with a fixed buffer (e.g. number of breakpoints is limited). I guess memory breakpoints are only possible with hardware support for them (I have no idea how to emulate them except emulating or setting breakpoints at all LOAD/STORE instructions). For symbolic debugging, the compiler would have to write some more debug symbols. For a start, <https://github.com/schierlm/OberonXref/blob/master/ORG.Mod.patch> annotates the code position for every instruction; I currently use it for creating combined source/assembly listings like <https://schierlm.github.io/OberonXref/ProjectOberon2013/ORP.html#both>. But you would probably also need some information about the stack layout (variable names and types) and register contents for every code locatoin, as well as information about module/global variables, and not-exported record types and record members. And you would also need some client to utilize all this information so that you can do something like "Debugger.Inspect F.vwr.dsc" :) So I guess for my own needs, that's too much work for the benefit (especially since I don't know if I will ever try to rewrite any of the core modules again). But perhaps I'm missing something? Any better ideas? Regards, Michael

1 1

A2 Repository
by peter＠easthope.ca 13 Apr '20

13 Apr '20

Hi, rev.9527 on Guenter's Web site is dated September 26. >From felix.friedrich ... Wed Jul 3 09:30:57 2019 > We are currently investing effort into cleaning up A2 ... > ... > ... we will make sure that native versions are properly supported again. > ... need to finish this work before October. Are native versions suitable for end users now? Hold off a little longer? Thanks, ... Peter E. -- https://en.wikibooks.org/wiki/Medical_Machines Tel: +1 604 670 0140 Bcc: peter at easthope. ca

3 4

Selfie
by Liam Proven 04 Mar '20

04 Mar '20

http://selfie.cs.uni-salzburg.at/ The inspiration of this system -- remarkable in itself -- may be of interest. It's mentioned at the bottom of the main page. -- Liam Proven – Profile: https://about.me/liamproven Email: lproven(a)cix.co.uk – gMail/gTalk/gHangouts: lproven(a)gmail.com Twitter/Facebook/LinkedIn/Flickr: lproven – Skype: liamproven UK: +44 7939-087884 – ČR (+ WhatsApp/Telegram/Signal): +420 702 829 053

2 1

Static variable overflow (bug?)
by Andreas Pirklbauer 01 Mar '20

01 Mar '20

Below is a slightly more elaborate variant that fixes the current bug in ORG.Put1a and makes MyViewers.Mod (see below) work on a Project Oberon 2013 system: PROCEDURE Put1a(op, a, b, im: LONGINT); VAR r: INTEGER; BEGIN (*same as Put1, but with range test -10000H <= im < 10000H*) IF (im >= -10000H) & (im <= 0FFFFH) THEN Put1(op, a, b, im) ELSIF op = Mov THEN Put1(Mov+U, a, 0, im DIV 10000H); IF im MOD 10000H # 0 THEN Put1(Ior, a, a, im MOD 10000H) END ELSE r := RH; IF b = RH THEN incR END ; Put1(Mov+U, RH, 0, im DIV 10000H); IF im MOD 10000H # 0 THEN Put1(Ior, RH, RH, im MOD 10000H) END ; Put0(op, a, b, RH); IF RH > r THEN DEC(RH) END END END Put1a; Comments: 1. Procedure incR is to be moved up to before procedure ORG.Put0 2. The use of incR ensures that in fact we do have enough registers available 3. Register optimization: But a new register is used only when needed (when b = RH) 4. Instruction optimization: For op = Mov, the extra MOV instruction at the end is avoided ---------------------------------------------------------------------------------------------------------------------- A simple fix to make the program “MyViewer” below work, i.e. to allow variable offsets < 64KB is to fix a bug in the current ORG.Put1a, by changing it From: PROCEDURE Put1a(op, a, b, im: LONGINT); BEGIN (*same as Put1, but with range test -10000H <= im < 10000H*) IF (im >= -10000H) & (im <= 0FFFFH) THEN Put1(op, a, b, im) ELSE Put1(Mov+U, RH, 0, im DIV 10000H); IF im MOD 10000H # 0 THEN Put1(Ior, RH, RH, im MOD 10000H) END ; Put0(op, a, b, RH) END END Put1a; To: PROCEDURE Put1a(op, a, b, im: LONGINT); BEGIN (*same as Put1, but with range test -10000H <= im < 10000H*) IF (im >= -10000H) & (im <= 0FFFFH) THEN Put1(op, a, b, im) ELSE Put1(Mov+U, RH+1, 0, im DIV 10000H); IF im MOD 10000H # 0 THEN Put1(Ior, RH+1, RH+1, im MOD 10000H) END ; Put0(op, a, b, RH+1) END END Put1a; i.e. by replacing RH with RH+1 in the ELSE clause. Note that this is a quick fix which neither checks whether there are in fact enough registers available (as incR does) nor does any register optimization. But it will make the program below work.. --------------------- MODULE MyViewer; (* Test of the menu line of a viewer *) IMPORT Display, Viewers, Oberon, MenuViewers, TextFrames; 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"; TYPE XYframe = POINTER TO XYframeDesc; XYframeDesc = RECORD (Display.FrameDesc) END; VAR bitmap: ARRAY max OF SET; (* with this variable present the menu may remain empty! *) PROCEDURE Restore(F: XYframe); BEGIN Oberon.RemoveMarks(F.X, F.Y, F.W, F.H); Display.ReplConst(Display.black, F.X, F.Y, F.W, F.H, Display.replace); (* clear *) END Restore; PROCEDURE Handle(F: Display.Frame; VAR M: Display.FrameMsg); VAR F1: XYframe; BEGIN CASE F OF XYframe: CASE M OF Oberon.InputMsg: IF M.id = Oberon.track THEN Oberon.DrawMouseArrow(M.X, M.Y) END | Oberon.CopyMsg: Oberon.RemoveMarks(F.X, F.Y, F.W, F.H); NEW(F1); F1^ := F^; M.F := F1 | MenuViewers.ModifyMsg: IF (M.Y # F.Y) OR (M.H # F.H) THEN F.Y := M.Y; F.H := M.H; Restore(F) END END END END Handle; PROCEDURE Open*; VAR F: XYframe; V: Viewers.Viewer; x, y: INTEGER; BEGIN NEW(F); F.handle := Handle; Oberon.AllocateUserViewer(Oberon.Par.vwr.X, x, y); V := MenuViewers.New(TextFrames.NewMenu("MyViewer", menu), F, TextFrames.menuH, x, y) END Open; END MyViewer.

3 4

Static variable overflow (bug?)
by Andreas Pirklbauer 27 Feb '20

27 Feb '20

> So I am suggesting to take every opportunity to factor out these constants. Thx for the lecture. Although in this particular case.. procedure ORG.Put1a will go away completely, once the problem is solved for all cases.

2 1

Static variable overflow (bug?)
by Andreas Pirklbauer 26 Feb '20

26 Feb '20

A simple fix to make the program “MyViewer” below work, i.e. to allow variable offsets < 64KB is to fix a bug in the current ORG.Put1a, by changing it From: PROCEDURE Put1a(op, a, b, im: LONGINT); BEGIN (*same as Put1, but with range test -10000H <= im < 10000H*) IF (im >= -10000H) & (im <= 0FFFFH) THEN Put1(op, a, b, im) ELSE Put1(Mov+U, RH, 0, im DIV 10000H); IF im MOD 10000H # 0 THEN Put1(Ior, RH, RH, im MOD 10000H) END ; Put0(op, a, b, RH) END END Put1a; To: PROCEDURE Put1a(op, a, b, im: LONGINT); BEGIN (*same as Put1, but with range test -10000H <= im < 10000H*) IF (im >= -10000H) & (im <= 0FFFFH) THEN Put1(op, a, b, im) ELSE Put1(Mov+U, RH+1, 0, im DIV 10000H); IF im MOD 10000H # 0 THEN Put1(Ior, RH+1, RH+1, im MOD 10000H) END ; Put0(op, a, b, RH+1) END END Put1a; i.e. by replacing RH with RH+1 in the ELSE clause. Note that this is a quick fix which neither checks whether there are in fact enough registers available (as incR does) nor does any register optimization. But it will make the program below work.. -ap --------------------- MODULE MyViewer; (* Test of the menu line of a viewer *) IMPORT Display, Viewers, Oberon, MenuViewers, TextFrames; 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"; TYPE XYframe = POINTER TO XYframeDesc; XYframeDesc = RECORD (Display.FrameDesc) END; VAR bitmap: ARRAY max OF SET; (* with this variable present the menu may remain empty! *) PROCEDURE Restore(F: XYframe); BEGIN Oberon.RemoveMarks(F.X, F.Y, F.W, F.H); Display.ReplConst(Display.black, F.X, F.Y, F.W, F.H, Display.replace); (* clear *) END Restore; PROCEDURE Handle(F: Display.Frame; VAR M: Display.FrameMsg); VAR F1: XYframe; BEGIN CASE F OF XYframe: CASE M OF Oberon.InputMsg: IF M.id = Oberon.track THEN Oberon.DrawMouseArrow(M.X, M.Y) END | Oberon.CopyMsg: Oberon.RemoveMarks(F.X, F.Y, F.W, F.H); NEW(F1); F1^ := F^; M.F := F1 | MenuViewers.ModifyMsg: IF (M.Y # F.Y) OR (M.H # F.H) THEN F.Y := M.Y; F.H := M.H; Restore(F) END END END END Handle; PROCEDURE Open*; VAR F: XYframe; V: Viewers.Viewer; x, y: INTEGER; BEGIN NEW(F); F.handle := Handle; Oberon.AllocateUserViewer(Oberon.Par.vwr.X, x, y); V := MenuViewers.New(TextFrames.NewMenu("MyViewer", menu), F, TextFrames.menuH, x, y) END Open; END MyViewer.

1 0

Re: [Oberon] Oberon OS / HAL / FPGA
by daniel.schmid＠bluemail.ch 26 Feb '20

26 Feb '20

Dear Oberon Listeners As a rather new user of Oberon (AOS build 9799) I am interested in whether there are really FPGAs on which Oberon runs? Does it have to do with the ETH PULP project (http://asic.ethz.ch)? Thanks a lot and kind regards Daniel ----Ursprüngliche Nachricht---- Von : oberon-request(a)lists.inf.ethz.ch Datum : 22/02/2020 - 12:00 (MN) An : oberon(a)lists.inf.ethz.ch Betreff : Oberon Digest, Vol 189, Issue 21 Send Oberon mailing list submissions to oberon(a)lists.inf.ethz.ch To subscribe or unsubscribe via the World Wide Web, visit https://lists.inf.ethz.ch/mailman/listinfo/oberon or, via email, send a message with subject or body 'help' to oberon-request(a)lists.inf.ethz.ch You can reach the person managing the list at oberon-owner(a)lists.inf.ethz.ch When replying, please edit your Subject line so it is more specific than "Re: Contents of Oberon digest..." Today's Topics: 1. Re: Project Oberon (was: Coding practice) (Skulski, Wojciech) 2. Re: Project Oberon (was: Coding practice) (Michael Schierl) 3. Re: Coding practice (Hans Klaver) 4. Re: Project Oberon (was: Coding practice) (Skulski, Wojciech) ---------------------------------------------------------------------- Message: 1 Date: Fri, 21 Feb 2020 19:08:19 +0000 From: "Skulski, Wojciech" <skulski(a)pas.rochester.edu> To: ETH Oberon and related systems <oberon(a)lists.inf.ethz.ch> Subject: Re: [Oberon] Project Oberon (was: Coding practice) Message-ID: <SN6PR07MB506914243460CA48D653ECD4FF120(a)SN6PR07MB5069.namprd07.prod.outlook.com> Content-Type: text/plain; charset="utf-8" Joerg: > As you know, Project Oberon has two parts: a) the Oberon OS and b) the HAL (HW abstraction layer) Physically it has the third layer, which is FPGA boards and emulators which can be termed "soft boards". I actually think that emulators are the most undervalued part of the project. They have a great potential. > a) The OS part of Project Oberon is collaborative, but perhaps in the peculiar way that you write your improvements in a mail to NW and he commits your request (or not). NW is a kind of ?human git?? The informal nature of this arrangement creates a problem, I think. > Andreas, Paul, myself, probably Chris and others provided input to NW to make the Oberon OS more stable and bug free. > The clearer you describe the error or the improvement including working code snipets, the more likely it is to be included by NW in a next release It would be more natural if the said persons formed a formal Advisory Committee with NW being a chairman. If you look around either the industry or academia, you will such committees everywhere. The Oberon community is an exception. The community could then discuss, submit propositions and patches to the Committee, which could then improve and prioritize the propositions. The final step would be an inclusion in the official system. The process would be open and transparent. Lacking a formal procedure is adversely affecting the progress. One can of course say "we do not need any damn progress", which is more or less the present situation. > b) In my point of view, NW sees his HAL (RISC5 instruction set, expected peripherals and memory layout) more or less as frozen. The only late addition he made to it were interrupts. This is both reasonable and good. It provides a stable base. The actual firmware implementation is rising some timing issues. The implementation can be fixed without touching the instruction set. > As long as any implementation (ASIC, FPGA, SoC, emulator) complies to the described HAL, the Oberon OS and especially the compiler works on it as is. This is great. > New HAL features can be added to Project Oberon. I added a 16 color display by changing VID.v and Display.Mod. Any practical instrument will need to add new peripherals. It can be done with new modules. It will not disrupt the foundation. > But this feature is not taken over into NWs release. ... And remember: colors need a lot of memory, so I had to reduce max code and heap size considerably to make 16 colors work in only 1 MB the board I have provides. BTW: The HAL is not bound to 1 MB. A compliant implementation can have up to 16 MB. A full HD display will take 2,073,600 bytes with 8 bit color. A board with 4 MB can afford this. There is no reason why the limitation of the ancient FPGA board dictates the BW display. The display resolutions and colors can be encapsulated in Display and/or SysDef and transparantly implemented w/o disrupting the base system. This is why I am advocating that the system is parametrized. Without parametrization any change will lead to a domino effect. With parametrization the changes will be possible. All that was actually envisioned in the NW book, but then he did not provide the properly parametrized foundation. > If you see the Oberon OS (especially the inner core) as a good base for embedded systems, 16 colors is of minor interest as most embedded system not even have a display at all. This is not true. Some instrumentation needs a display. It is not right to say "this design is limited by an ancient technology, but this is OK because a more general design is not needed anyway". Wojtek -------------------------------------------- > Am 21.02.2020 um 04:02 schrieb Skulski, Wojciech <skulski(a)pas.rochester.edu>: > > ?Chris: > > thank you for the summary. I suspect we can wrap up this discussion as follows. (1) We roughly agree that a good style exists and it has even been written up. (2) Not much will change in any variant of the Oberon System (except Astrobe, where there is constant progress). > > I base prediction #2 on the dictionary definition of the word "project", which says "an individual or collaborative enterprise that is carefully planned and designed to achieve a particular aim". > > In that sense "Project Oberon" is not a project despite its name. There is no "collaborative enterprise that is carefully planned". There is no "particular aim". In particular, improving Oberon System code quality is not an aim which we would all agree upon. For this reason it is not likely to be achieved. I hope this prediction will be proven wrong. > > Lacking a collaborative project, there are several individual "Oberon Projects". They remain disjoint and pursued in isolation. Not much is moving forward on a common FPGA Oberon System frontier despite seven years since the original release. Things have actually deteriorated because the FPGA boards have disappeared, what was only partly compensated by the Oberon System emulators. An emulator without an actual board has a somewhat limited function. > > If there was a common FPGA Oberon System project, then how it would look like? (I know I am dreaming.) Here is my own individual dream list concerning the FPGA Oberon System, which is my main interest. > > 1) A project means collaboration among people. So the first step would consist of forming a team willing to communicate and to collaborate on a common FPGA Oberon System. > > 2) The team would agree on a set of achievable goals. > > 3) The team would prioritize the goals and assign them to its members. > > 4) Any FPGA project consists of HW, FW, and SW which need be co-developed in parallel. The list of tasks and responsibilities would follow this division. > > 5) Based on the experience with the present System, augmented with emulators, the team would agree on the FPGA board architecture and features. I submit to consideration that the FPGA board would provide two or four MB, preferably of the synchronous type which delivers better performance than ASRAM. Having more than a single MB would allow to add color to the display, as well as develop more ambitious applications. > > 6) Designing a new board may not be even necessary. Five RiskFive sets exist and these can be distributed among the team. So this step can be short circuited. More such sets can be manufactured by any team member. I can provide the design files and the BOM. > > 7) Simplified and cheaper board versions can be eventually designed. Other boards can get adopted to the project. (Preferably no SDRAM which is hard to interface.) > > 8) The next ingredient is the FW. The current version of RISC5.v is not ideal. Considerable discussion can be devoted to fixing the timing flaws. Team members versed in FPGA firmware could work on fixing RISC5.v. > > 9) The RISC5top.v seems to be surprisingly resilient. The FPGA board designs should take this into account by providing peripherals served by the RISC5top. RiskFive is very close to doing this. We actually achieved this stage. > > 10) I am strongly advocating that factoring out the memory locations in the code will help while working on HW and FW interfacing. I have already done and published this step. > > 11) Ethernet can be brought back to Oberon System with the addition of Ethernet controller(s) to the HW. This has been done with RiskFive, which is Ethernet-ready. Other FPGA boards (to be developed) can add their own variants of Ethernet controllers. > > 12) After achieving the above, the Oberon System code would be ready for a serious facelift. Ethernet services, printing, file sharing, or remote program execution are all among possible facelifts, according to individual interests. > > 13) After achieving the above, the team could continue pushing the Oberon System to become a contender against MicroPython or FreeRTOS, for example. There would be enough momentum in the collaboration that such ambitious goal can become a reality. > > Please note that the above list, though maybe long, is kind of logical. Most of these steps follow one after another in a natural order. > > How likely is it to happen? > > Wojtek > > > > -- > Oberon(a)lists.inf.ethz.ch mailing list for ETH Oberon and related systems > https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.inf.ethz.ch_mail… -- Oberon(a)lists.inf.ethz.ch mailing list for ETH Oberon and related systems https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.inf.ethz.ch_mail… ------------------------------ Message: 2 Date: Fri, 21 Feb 2020 23:22:21 +0100 From: Michael Schierl <schierlm(a)gmx.de> To: "Skulski, Wojciech" <skulski(a)pas.rochester.edu>, ETH Oberon and related systems <oberon(a)lists.inf.ethz.ch> Subject: Re: [Oberon] Project Oberon (was: Coding practice) Message-ID: <b45acd45-61d1-19fc-214a-3d3adc367c59-6628(a)gmx.de> Content-Type: text/plain; charset=utf-8 Hello Wojtek, Am 21.02.2020 um 04:01 schrieb Skulski, Wojciech: > If there was a common FPGA Oberon System project, then how it would look like? (I know I am dreaming.) Here is my own individual dream list concerning the FPGA Oberon System, which is my main interest. > > 1) A project means collaboration among people. So the first step would consist of forming a team willing to communicate and to collaborate on a common FPGA Oberon System. > > 2) The team would agree on a set of achievable goals. In my opinion the order is wrong here. Successful collaboration requires first to determine the goals (and non-goals) of the collabroration, because depending on how the goals match, different members may join or not. And it does not only matter if goals are achievable (by the members), but also if they are desirable (to most members). [A good example was the Subversion VCS project, which defined first that they want to build a centralized version control system, and which features are in-scope and which are out-of-scope. Then they attracted like-minded people and were able to achieve their vision, by closing any feature requests that were out-of-scope of their vision as WONTFIX.] I guess there are at least 5 people in the list who are interested in "improving Project Oberon", but what is an improvement to some of them is a feature-creep or deterioration to others. Which also explains that there are different code bases. For example, some time ago I suggested removing some unused exported members, like Display.Handle, from some Project Oberon modules, and un-exporting some others, to make coupling lower and make it easier to understand some code; and immediately I got some reactions why you cannot remove them - "What if somebody wants to create a different windowing/input manager? What if somebody wants to extend this or that?". My answer would be "If they really want, they would have to add this, or something similar, back". Another example is actual hardware availability. For me it is enough that at some point in time, actual hardware existed to run the thing (proving that the design is indeed implementable in real hardware), and that today there are some means to still run the thing (which need not be hardware, but emulation is fine). So what is an improvement to the system for me is the opposite for others, and vice versa. Regards, Michael ------------------------------ Message: 3 Date: Fri, 21 Feb 2020 22:57:51 +0100 From: Hans Klaver <hklaver(a)dds.nl> To: ETH Oberon and related systems <oberon(a)lists.inf.ethz.ch> Subject: Re: [Oberon] Coding practice Message-ID: <EED11038-B551-4ABD-96BC-7CF53C1B4787-2319(a)dds.nl> Content-Type: text/plain; charset="us-ascii" As I found this Omi document Programming Conventions very useful and instructive for Oberon and Component Pascal programmers, deserving wider circulation, a few years ago I made a .pdf document of it (by means of 'printing to PDF'), which can be found here: https://hansklav.home.xs4all.nl/oberon.shtml <https://hansklav.home.xs4all.nl/oberon.shtml> There you can also find a link to a document that deserves to be better accessable to the Project Oberon community: the book The Oberon System, User Guide and Programmer's Manual, by Martin Reiser. This is the first volume of the 'Oberon Trilogy', describing an early (1990) version of the Oberon System in a very clear and informative way, imho still useful for the present Project Oberon 2013 user and programmer. The .pdf file resides on the oberoncore.ru <http://oberoncore.ru/> website. I own a hardcopy of this book, which I bought in 1991 and which sparked my interest in Oberon. Not only is it very well written but it is the book with the most attractive lay-out of all Oberon books! -- Hans Klaver > The guys at Oberon microsystems published a set of Programming Conventions > for Oberon/L a.k.a. Component Pascal. It is included in the Help file with > the Blackbox Component Pascal system. Several possible styles i.e. multiple > statements on one line, statements split over several lines etc. are > considered to be good practice. Thankfully, nobody is forced or constrained > by the Oberon language itself (unlike some languages) to use a prescribed > programming style. > > Rather than inventing our own programming conventions, we adopted those, > with the kind permission of Oberon microsystems, for the Astrobe development > system. If you do not have access to the original Blackbox document refer to > Chapter 8. 'Programming Conventions and Guidelines' in the 'ARM Cortex-M > Oberon Programmers Guide' which you can download from: > > https://www.astrobe.com/Oberon.htm > > When I'm writing new code from scratch then I use my own personal > preferences (which can change from one month to another!) However, if I am > making minor modifications to existing code I try to follow the principle of > 'when in Rome do as the Romans do' and adopt a similar style to the original > author. If these principles are not followed the result can be code that > looks as ugly as a one-page document written in 17 different fonts. > > Regards, > Chris Burrows > CFB Software > https://www.astrobe.com > > > -- > Oberon(a)lists.inf.ethz.ch mailing list for ETH Oberon and related systems > https://lists.inf.ethz.ch/mailman/listinfo/oberon

4 3

WinAOS.
by peter＠easthope.ca 26 Feb '20

26 Feb '20

Hi, I understand the procedure of making a local archive from the SVN A2 archive at the ETH. The emulator can run in Windows and other systems. Guenter Feldmann's UnixAos also remains viable. To my understanding it is the forerunner of the SVN archive. http://www.ocp.inf.ethz.ch/ is not responding. Is a WinAos analogue of UnixAos still available? If so, will someone please tell me how to find an installation archive. The old installation instructions must be in archive.org or similar but my brief search effort didn't find them. Thanks, ... P. -- https://en.wikibooks.org/wiki/Medical_Machines https://en.wikibooks.org/wiki/Oberon Tel: +1 604 670 0140 Bcc: peter at easthope. ca

4 12

Static variable overflow (bug?)
by Andreas Pirklbauer 24 Feb '20

24 Feb '20

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

3 3