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

Re: [Oberon] Oberon on Nexys DDR4 from Digilent?
by Paul Reed 19 Feb '18

19 Feb '18

> thank you. Oberon System has so much speaking against it... Not from anyone whose opinion I value ;-)

1 0

Importing string constants in PO
by Peter Matthias 19 Feb '18

19 Feb '18

Importing string constants does not work in PO. Strings from same module are shown. For ARM and RISC-V compiler I changed string addresses to negative values to have easy PC-relative access to module data. Unfortunately this also changes the symbol file. But fortunately string constants are not used in the system so I disabled them. Peter

1 0

Re: [Oberon] Oberon on Nexys DDR4 from Digilent?
by Paul Reed 19 Feb '18

19 Feb '18

Dear W. > would you mind explaining how are Meltdown, Spectre, or Rowhammer related > to Oberon running on RISC5 in the FPGA? Well joking aside, they are examples of hardware becoming too clever for its own good, which is what efforts like Oberon are intended to avoid. https://en.wikipedia.org/wiki/Row_hammer https://en.wikipedia.org/wiki/Meltdown_(security_vulnerability) HTH Paul

2 1

Re (2): Re (2): Documentation for Fox compiler.
by peter＠easthope.ca 19 Feb '18

19 Feb '18

> PaCo stands for Parallel Compiler. It was an acronym for scope parallel > compiler, where every scope was compiled by an independent thread. Thanks. The PACO entry in the glossary now has a meaning attached. https://en.wikipedia.org/wiki/Oberon_(operating_system)#Glossary Probably can be expressed better. Correction or criticism welcome. ... Lyall E. -- 123456789 123456789 123456789 123456789 123456789 123456789 123456789 Tel: +1 360 639 0202 Pender Is.: +1 250 629 3757 http://easthope.ca/Peter.html Bcc: peter at easthope. ca

1 0

Re (2): Documentation for Fox compiler.
by peter＠easthope.ca 19 Feb '18

19 Feb '18

Joerg, From: =?utf-8?B?SsO2cmc=?= <joerg.straube(a)iaeth.ch> Date: Fri, 2 Feb 2018 14:43:59 -0800 > Fox is the compiler for ActiveOberon (AOS, A2, Bluebottle=E2=80=A6). Thanks. I've added to the glossary. https://en.wikipedia.org/wiki/Oberon_(operating_system)#Glossary PACO was the original compiler in AOS? It's an acronym. Parse And Comile Oberon or Parse Active Compile Oberon(??)? Any ideas about the origin of the "Fox" name? Thanks, ... Lyall E. -- 123456789 123456789 123456789 123456789 123456789 123456789 123456789 Tel: +1 360 639 0202 Pender Is.: +1 250 629 3757 http://easthope.ca/Peter.html Bcc: peter at easthope. ca https://en.wikibooks.org/wiki/Medical_Suction_Machines https://en.wikibooks.org/wiki/Oberon

3 3

A CASE quiz
by Andreas Pirklbauer 19 Feb '18

19 Feb '18

> The increase in size of the compiler sources is > about 250 lines of code, i.e. an increase of 7%. > ... > Chris Burrows In the Oberon compiler for Oberon on Ceres, which targets the NS32000, the implementation is about 120 lines of code, (procedures Compiler.{CaseLabelList, StatSeq.CasePart}, OCH.{CaseIn, CaseOut}), and uses a straightforward method to construct the jump table in OCH.CaseOut (from lowest to highest bound). Difference between CISC and RISC or do you some special optimization not present in the Ceres implementation?

2 1

CASE without ELSE
by Andreas Pirklbauer 18 Feb '18

18 Feb '18

> It would take some time (more than I currently > have!) to prove whether or not this is the case. > suspect that there is no other single CASE in > PO2013 that would have the same impact > but there are a few areas in the compiler > where CASE statements could be reinstated > and the cumulative improvements could be significant. I like your systematic approach to such questions. Gives you hard data which form the basis of sound(er) arguments. As for the potential improvements in the compilation speed, my ingoing hypothesis would be that ORS.Get is where the biggest improvement is still to be expected, as it has the most cases. The others (ORP.StandFunc, ORP,StandProc and ORP.factor, etc) may cumulatively contribute another 5-10% or so perhaps. But hard to say without doing the experiment. It would be instructive to construct something resembling the “space-time map”, as shown in Arthur Sale’s paper for modern RISC processors (or the RISC used in PO2013). The graph shown in the paper cannot really be used as a reliable quantitative proxy as the Burroughs 7700 had special hardware support built in. Nevertheless, it’s an instructive qualitative insight. > However, this assumes that programmers have bothered > to think about which branches are likely to occur more > frequently and shuffle their IF-ELSIFs so they are near the top. Or at least such that they roughly correspond to a “search tree” as described in Arthur Sale's paper. ORS.Get in PO2013 is an example, but it’s not perfect, because there, the subranges don’t lead to an optimum comparison tree.

1 0

CASE without ELSE
by Andreas Pirklbauer 18 Feb '18

18 Feb '18

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

1 0

CASE without ELSE
by Arthur Yefimov 17 Feb '18

17 Feb '18

Andreas wrote: > One just needs to get the order right: extended types first, base type last (if one placed the base type at the beginning of the list, it would always evaluate to TRUE even if M were an extension of T) Does it mean that CASE statement for pointer/record types work like an IF statement? Does it sequentially check all options one by one until it hits the right one? In this case, what does "CASE" give in comparison to using "IS" clause, i.e. "IF obj IS MyViewer THEN ... ELSIF obj IS ..."?

3 2

Re: [Oberon] CASE without ELSE
by Josef Templ 17 Feb '18

17 Feb '18

The latest Oberon language definition by NW that I have found is Revision 1.10.2013 / 3.5.2016 (see http://people.inf.ethz.ch/wirth/Oberon/Oberon07.Report.pdf) It does have a numeric CASE statement. My interpretation of what might have happened is this: In Oberon07 the numeric CASE had been dropped, but later it has been reintroduced but the ELSE has been forgotten. To me, a numeric CASE without an ELSE is pointless. The compiler needs to emit a range check anyway for generating a TRAP if there is no ELSE. The ELSE part comes (almost) for free. If the ELSE check is done outside the CASE, it is actually done twice. In contrast to some postings, by the way, the labels are not forced to start with 0 and they can also be negative (by specifying a negative named constant). In a real implementation, it would be much simpler to allow any ConstantExpr of appropriate result type, though. My conclusion so far is: If the numeric CASE is not implemented but only specified, it should not be taken literally. - Josef

3 2