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

Running Ceres3 code on ... FPGA
by Darek Maksimiuk 23 Feb '18

23 Feb '18

I am not sure if you are aware of the following development by Udo Möller: http://cpu-ns32k.net and here: https://opencores.org/project,m32632. Udo has stated that implementation of the NC32xxx was purely for fun. I am planning (when time permits) to play with this CPU on my DE-10 Nano board. Then I will try to run a Risc-5-based PO on it. Regards, Darek

1 0

Life without local procedures
by Andreas Pirklbauer 23 Feb '18

23 Feb '18

> I can live without intermediate variables, especially > if they simplify and improve compiler code generation. Only intermediate *variables* complicate code generation and slowdown runtime performance (when calling an intermediate procedure,and when subsequently accessing intermediate variables). Intermediate *constants* and *types* come for free, both in thecompiler and at runtime, as their values are known at compile time. This may have been one reason why access to intermediate *constants*and *types* is still allowed in the Oberon-07 revision, whereas accessto intermediate *variables* has been disallowed (however: intermediateconstants and types are *never* accessed from nested scopes in Oberon)

1 0

Reviving Oberonstation
by Frans-Pieter Vonck 22 Feb '18

22 Feb '18

Tomorrow evening at Techinc (Hackerspace Amsterdam) I will try to revive an Oberonstation. https://wiki.techinc.nl/index.php/Electronics_Friday_VIII Greets, F.P. Vonck

1 0

Oberon on Nexys DDR4 from Digilent?
by Travis Ayres 22 Feb '18

22 Feb '18

Is there a port underway? I'd like to use Oberon on this board. On Feb 19, 2018 3:00 AM, <oberon-request(a)lists.inf.ethz.ch> wrote: > 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. CASE without ELSE (Andreas Pirklbauer) > 2. CASE without ELSE (Andreas Pirklbauer) > 3. A CASE quiz (Andreas Pirklbauer) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 18 Feb 2018 22:37:02 +0100 > From: Andreas Pirklbauer <andreas_pirklbauer(a)yahoo.com> > To: oberon(a)lists.inf.ethz.ch > Cc: Andreas Pirklbauer <andreas_pirklbauer(a)yahoo.com> > Subject: [Oberon] CASE without ELSE > Message-ID: <99A08E58-C6CC-4D57-A173-89917A617147(a)yahoo.com> > Content-Type: text/plain; charset="us-ascii" > > > > Does it mean that CASE statement for pointer/ > > > record types work like an IF statement? > > > Yes, it is a syntactic sugar for IF/ELSIF > > and type guard, nothing more. > > A key difference to the IF statement > > IF t IS T1 THEN S1 > ELSIF t IS T2 THEN S2 > ... > END > > is that in the CASE statement > > CASE t OF > T1: S1 | > T2: S2 | > ... > END > > the dynamic type t of the case expression is set to the type of the > selected case, i.e. in the statements S1 labeled by T1, the case variable t > is considered as of type T1, etc. > > This implies that no type guard t(T1) is needed in S1, etc, i.e. one can > just write t instead. >

7 9

NEW with anonymous records
by Andreas Pirklbauer 21 Feb '18

21 Feb '18

> Except if you have an explicit answer by him > that pointers must point to named records. Not really except that the change had been planned for a while now. I remember this topic popped up every now and then already in the Modula-2 days in the 80s, when we writing compilers for then-current processors at ETH.. without ever settling on the question of whether this should merely stay an implementation restriction or (one day) become part of the official language spec (at least I have not seen it in any language specs..) I don’t it’s a particularly interesting question. One just needs to make a decision. Andreas

4 5

NEW with anonymous records
by Andreas Pirklbauer 20 Feb '18

20 Feb '18

> Project Oberon 2013 mainly implements a version > of Oberon-07 report released during 2011, it's the > code that hasn't been updated. The only features > added during 2013 were the typecase and byte, > the rest of the compiler is out of sync. Nope. The code to restrict pointers to *named* records was indeed added in September 2017, as stated earlier. I know so because I wrote it..

2 1

Importing string constants in PO
by Andreas Pirklbauer 20 Feb '18

20 Feb '18

> Thanks for clarification. Although I think > ORG.Mod should be updated to give an > error when importing string constants, > like I will do in my ORGx.Mod > Peter I think you are right. This is perhaps the better thing to do. I just sketched what changes to the compiler would be needed to *allow* (and correctly handle) access to imported string constants. And now that I have done THAT (it’s not difficult, but it requires some shenanigan with item conversions in ORG.loadStringAdr, ORG.StrToChar, ORG.CopyString, etc. to use the SB base of the exporting module if needed, and also setting org.lev also for constants), I agree with you that one should just issue an error message when an external string is accessed - which of course is a trivial change to the compiler. Or not even allow string constants to be exported in the first place. This would effectively turn them into aliases for string literals visible only in the module where they are declared. One of those things that one *could* debate endlessly, but where a debate is not really worth our time.. Andreas

1 0

NEW with anonymous records
by Andreas Pirklbauer 20 Feb '18

20 Feb '18

> Just to clarify, this is a restriction of > the PO 2013 compiler, and not something > which is specified in the language report. The language report has indeed not been updated. The second sentence in section 6.4. still reads “it must be a record type” and not “.. a named record type"

2 1

NEW with anonymous records
by Andreas Pirklbauer 20 Feb '18

20 Feb '18

> I believe this problem was addressed in the 23.9.2017 > update of Project Oberon with a language restriction > implemented in ORP.Mod. If you try to compile the > code above you will now get the error message: > > "Error: must point to named record” > Correct. This is when it happened. It came out of a discussion about type descriptors and a suggestion I had made back then. Prior to 23.9.2017 it possible to declare pointers to *anonymous* records eg: TYPE T = POINTER TO RECORD .. END. The issue with this was that the compiler did not (and still does not) create type descriptors for *anonymous* records. This created a problem if a dynamic variable pointing to an *anonymous* record type is allocated via the predefined procedure NEW (which accesses the type descriptor to obtain the size of the record about to be allocated in the heap). Solution #1 is to also create type descriptors for *anonymous* records, which could be accomplished by changing ORP.Type0 to: IF type.base.form # ORB.Record THEN ORS.Mark("must point to record”) ELSIF type.base.typobj = NIL THEN ORG.BuildTD(type.base, dc) (*type descriptor; len used as its address*) END Solution #2 is to restrict pointers to *named* records, which is accomplished by replacing the above IF statement in ORP.Type0 to: IF (type.base.form # ORB.Record) OR (type.base.typobj = NIL) THEN ORS.Mark("must point to named record”) END Solution #2 was retained. It leads to more readably code, even though the necessity to declare a pointer type AND its record type my be perceived as somewhat annoying. But one can certainly live with it. Andreas

3 2

NEW with anonymous records
by Peter Matthias 20 Feb '18

20 Feb '18

When allocating memory of a pointer to an anonymous record in PO, system crashes after time. How to fix or disable this behaviour? VAR a: POINTER TO RECORD c, d: INTEGER END; ... NEW(a) Peter

2 1