[Oberon] Oberon on Nexys DDR4 from Digilent?

Mon Feb 19 17:24:06 CET 2018

Is there a port underway?
I'd like to use Oberon on this board.

On Feb 19, 2018 3:00 AM, <oberon-request at lists.inf.ethz.ch> wrote:

> Send Oberon mailing list submissions to
>         oberon at 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 at lists.inf.ethz.ch
>
> You can reach the person managing the list at
>         oberon-owner at 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 at yahoo.com>
> To: oberon at lists.inf.ethz.ch
> Cc: Andreas Pirklbauer <andreas_pirklbauer at yahoo.com>
> Subject: [Oberon]  CASE without ELSE
> Message-ID: <99A08E58-C6CC-4D57-A173-89917A617147 at 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.
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://lists.inf.ethz.ch/pipermail/oberon/attachments/20180
> 218/d72f2544/attachment-0001.html>
>
> ------------------------------
>
> Message: 2
> Date: Sun, 18 Feb 2018 22:40:42 +0100
> From: Andreas Pirklbauer <andreas_pirklbauer at yahoo.com>
> To: oberon at lists.inf.ethz.ch
> Cc: Andreas Pirklbauer <andreas_pirklbauer at yahoo.com>
> Subject: [Oberon]  CASE without ELSE
> Message-ID: <24E90C01-555F-4253-936A-C62BDED4E121 at yahoo.com>
> Content-Type: text/plain; charset="utf-8"
>
>   > 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.
>
>
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://lists.inf.ethz.ch/pipermail/oberon/attachments/20180
> 218/62e01130/attachment-0001.html>
>
> ------------------------------
>
> Message: 3
> Date: Mon, 19 Feb 2018 00:44:10 +0100
> From: Andreas Pirklbauer <andreas_pirklbauer at yahoo.com>
> To: oberon at lists.inf.ethz.ch
> Subject: [Oberon]  A CASE quiz
> Message-ID: <AF009A2D-D176-4D9E-8C57-FFB7E3550E6C at yahoo.com>
> Content-Type: text/plain; charset="us-ascii"
>
>   > 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?
>
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://lists.inf.ethz.ch/pipermail/oberon/attachments/20180
> 219/eeebf5a2/attachment-0001.html>
>
> ------------------------------
>
> Subject: Digest Footer
>
> --
> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
> https://lists.inf.ethz.ch/mailman/listinfo/oberon
>
>
> ------------------------------
>
> End of Oberon Digest, Vol 165, Issue 14
> ***************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.inf.ethz.ch/pipermail/oberon/attachments/20180219/62968a74/attachment.html>