January 2021 - Oberon - mailman3.inf.ethz.ch

RISC5 Architecture
by Hellwig Geisse 06 Jan '21

06 Jan '21

Dear all, I want to open just another can of worms... ;-) Do we have a common dependable definition of the standard hardware the Oberon software is expected to run on? I think that the defining document should be "The RISC Architecture" [1], which bears the date "NW 5.12.10, rev. 9.8.2018". This is the latest document on RISC5 I'm aware of. I think that this paper does not answer the following questions (please note that I myself guessed answers while writing my RISC5 simulator, but I was never sure to have guessed right): 1. What is the endianness of RISC5? 2. Is the offset in memory instructions (format F2) sign-extended? 3. The SUB instruction "also sets the C flag". How is this to be interpreted? Example: compute 3-5. If you really subtract in binary, the carry will be set. If you add -5 in 2's complement representation, the carry will be cleared. 4. What happens on (synchronous) exceptions? a) unaligned word access b) unknown instruction c) division by zero d) floating-point overflow e) floating-point underflow 5. What happens exactly on interrupt? 6. Are nested interrupts supported? 7. Does STI delay the setting of intenb by one instruction? Does RTI automatically set intenb? If both questions are answered negatively, then there is a race condition in the sequence (STI, RTI), with a nested interrupt as a possible result. 8. Can external devices other than the timer interrupt? 9. All external devices are grossly underspecified. (The list is not complete.) Although I really want these questions to be answered, what interests me most is: *how* do we find answers to them? Some alternatives are: - Anything that is not specified is intentionally left so. Implement at your free choice. This will severely hamper exchanging software, especially in binary form. - Take NW's implementation and analyze the circuits (or just try it out). This promotes his implementation to a "reference design". - Choose any one of the various simulators and declare it to be the "gold standard". Which one? - Discuss each question here on the list and come to an agreement. A bit cumbersome, but manageable. Other ideas? Thanks, Hellwig [1] https://people.inf.ethz.ch/wirth/FPGA-relatedWork/RISC-Arch.pdf

3 4

First stable release v1.0 of Extended Oberon available
by Andreas Pirklbauer 05 Jan '21

05 Jan '21

> I now have to check what it takes to get THM-Oberon up-to-date :-) A one time exercise. Unfortunately, I don’t know which experimental version you were basing your work on in the past. A ‘diff' should help. But from now on, old releases won’t be removed and there will be documented upgrade paths to future releases, if necessary. For example, when Extended Oberon becomes available on RISC-V..

1 0

First stable release v1.0 of Extended Oberon available
by Andreas Pirklbauer 05 Jan '21

05 Jan '21

Since several people have expressed an interest in basing their work on it: After the initial experimentation phase, there is now a first stable release of Extended Oberon 1.0, available on Github. There may of course be future experiments and future releases.

2 1

LOOP conversion
by Bernhard Treutwein 05 Jan '21

05 Jan '21

Our russian friends had a very long thread about conversion of LOOP - EXIT https://forum.oberoncore.ru/viewtopic.php?f=82&t=2547 it is readable and understandable with Google translate ... I personally think that deliberate and good use of LOOP is not that bad. E.g., I find LOOP Step; IF cond THEN EXIT END; CodeBlock END more attractive and readable than Step; WHILE ~cond DO CodeBlock; Step END -- Bernhard

6 10

Re: [Oberon] Lola-2 vs Verilog (was: Module finalization - language construct or system call)
by Chris Burrows 05 Jan '21

05 Jan '21

> -----Original Message----- > From: Oberon [mailto:oberon-bounces@lists.inf.ethz.ch] On Behalf Of > Skulski, Wojciech > Sent: Tuesday, 5 January 2021 6:08 AM > To: ETH Oberon and related systems > Subject: Re: [Oberon] [EXT] Module finalization - language construct > or system call > > Yes, I would like to develop practical applications. I am not > adversarial to LOOPs and friends. It is infinitely better than > Verilog which we cannot avoid in this project. I love LOOPs after > looking at Verilog. Any Oberon construct looks lovely after looking > at the Verilog. > Looking at the Verilog code is this project is like looking at the assembler output from the Oberon compiler. The FPGA configuration code is actually written in Wirth's 'Logic Description Language' Lola-2. The Verilog code is the output after the Lola code has been processed by the Lola compiler The Lola compiler and the Lola definition of the RISC5 computer are here: https://people.inf.ethz.ch/wirth/Lola/index.html It is not quite as pretty as Oberon-07 source code but it is a distinct improvement on the resulting Verilog code. When I started Astrobe for RISC5 in 2013 I had originally planned 3 phases for the implementation. Phase 3 included integrating the Lola compiler into the Astrobe IDE so that you could run it on Windows. I just revisited that plan. Inevitably it has changed along the way and the Lola compiler is now included in the fourth of five phases. The god news is that everything that appeared before it has now been done. I'm real busy doing some work for ARM Oberon-07 users right now but when that is complete I'll revisit the Lola-2 plan, Regards, Chris Chris Burrows CFB Software https://www.astrobe.com/RISC5

2 1

Module finalization - language construct or system call
by Andreas Pirklbauer 04 Jan '21

04 Jan '21

> 1) Some "we" are perfecting the language itself, even if the improvements are breaking the legacy code. > 2) Some "we" would like to develop practical applications with a reasonable time and effort. > 3) Some "we" believe in "do not fix it if it ain't broken". Some others think this statement has no value. > > We have not agreed on a basic question "should Oberon be used for practical developments, > or should it be perfected regardless of whether it is used”. > > There seem to be diverging opinions on this subject. As there should be.. I probably fall in your 1) camp, whereas you seem to fall in the 2) camp. However, I have decided to build on a solid foundation, which happens to be Oberon-07, and NOT (!) Original Oberon or Original Oberon-2. Therefore, this choice automatically breaks *any* legacy code that was written before Oberon-07 came along - no matter whether Oberon-07 is extended or not. But I actually don’t break the Oberon-07 foundation, I only add to it (strict superset).

2 1

Module finalization - language construct or system call
by Andreas Pirklbauer 04 Jan '21

04 Jan '21

> Generally, I agree with Hellwig that I like FINAL, Finalize… > better than Close. https://en.wikipedia.org/wiki/Finalizer The keyword has been changed from CLOSE to FINAL. Breaks with with the Component Pascal tradition, but makes more sense indeed. > We can do whatever we want, but it won't be Oberon-07 anymore… Well, the particular compiler, where the FINAL construct has (now) been introduced *already* is a dialect of Oberon-07 (it has added type-bound procedures, uniform handling of variable access, etc), so introducing yet another language feature won’t really change this property. However, the compiler implements a *strict superset* of Oberon-07, so at least all bona-fide Oberon-07 programs will compile (backward compatible).

1 0

Module finalization - language construct or system call
by Andreas Pirklbauer 04 Jan '21

04 Jan '21

I would like to solicit input on whether to realize “module finalization” via a CLOSE language construct or via a system call such as Modules.Close. See the test module M below. Both are currently available in Extended Oberon, both are trivial to implement (only a few lines each), but the question is what one *should* offer. Some arguments in favour or against these 2 options include: 1) CLOSE as a language construct: - A entire language construct for a (probably) rarely used feature - Creates another dialect of Oberon-07, limiting portability of programs + clean solution + one does not need to import module Modules + Ease of porting for Component Pascal modules 2) Modules.Close as a system call: + no need for a separate language construct + sufficient for the (rare) cases where it is used - need to add Modules.Close in all systems if one wants portability - one has to import module Modules ———————————————————————— 1) CLOSE as a language construct: MODULE M; IMPORT Texts, Oberon; VAR W: Texts.Writer; PROCEDURE Start*; BEGIN END Start; (*load module*) BEGIN (*module initialization sequence*) Texts.OpenWriter(W) CLOSE (*module finalization sequence*) Texts.WriteString(W, "Finalizing module M…"); Texts.WriteLn(W); Texts.Append(Oberon.Log, W.buf) END M. ORP.Compile M.Mod/s ~ # compile module M M.Start ~ # load module M System.Free M ~ # unload module M (prints "Finalizing module M…”) ———————————————————————— 2) Modules.Close as a system call: MODULE M; IMPORT Modules, Texts, Oberon; VAR W: Texts.Writer; PROCEDURE Close; BEGIN Texts.WriteString(W, "Finalizing module M…"); Texts.WriteLn(W); Texts.Append(Oberon.Log, W.buf) END Close; PROCEDURE Start*; BEGIN END Start; (*load module*) BEGIN Texts.OpenWriter(W). Modules.Close(Close) END M. ORP.Compile M.Mod/s ~ # compile module M M.Start ~ # load module M System.Free M ~ # unload module M (prints "Finalizing module M…")

4 5

LOOP conversion
by Andreas Pirklbauer 04 Jan '21

04 Jan '21

> This is exactly a reason why LOOP/EXIT shouldn't be > allowed by the compiler not even for "porting” reasons > Jörg Agreed. So it now seems that an even better approach to port V4 may be to *first* clean up V4 *on* a running V4 system (i.e. replace all LOOP, EXIT, RETURN, etc) in a step by step fashion *while* keeping the V4 system running, and *then only* compile V4 for RISC5, either using a cross-compiler on V4 or on RISC5 itself.

1 0

[EXT] Porting S3 / V4 Oberon
by Andreas Pirklbauer 04 Jan '21

04 Jan '21

> > That way, one doesn’t need to amend the Oberon-07 compiler. > > There is now a confusion. When Chris or Joerg say "Oberon-07”, > they both mean the original NW compiler with minor modifications. > When you say "Oberon-07", then you most likely mean your > own compiler with Oberon-2 type bound methods. Correct? Yes, you’re right. PS: Note that the Extended Oberon compiler is still an "Oberon-07” compiler… but with Oberon-2 type-bound methods added :-)

1 0