[Oberon] Numerical CASE Statements in Project Oberon

[Jan de Kruyf]

This is Ada, or set membership Chris, but you might have it included in
your compiler.

"x IN s stands for "x is an element of s". x must be of type INTEGER, and s
of type SET."

both in O-2 and O-7.
While I was comparing character or integer conditionals. Sure, in real life
if your cases are
under 32 you might choose to use a set rather than a case construct.
---

But I want to ask you something that you might know:
For starters I modified the Parser and the code Generator under norebo from
Peter de Wachter
which is a derivative of his RISC intepreter. In any case this worked fine.

Then I modified the Scanner of the compiler to have the case construct.
This also implied recompiling ORB.
Everything compiled fine, but noway can I get the complete compiler to run.

It brakes on a STR or LDR instruction that is used as a Linux kernel signal
/ call,
but the IO address is not right the runtime says.

So I am a bit at loss here. Did Peter modify the compiler source code at
all to accomodate his
Linux interface or is it some silly bug I introduced?

Have you used his interpreter at all?

Thanks,

j.


On Sat, Nov 28, 2015 at 2:18 PM, Chris Burrows <chris at cfbsoftware.com>
wrote:

> Maybe so, but that is not a fair comparison. I would have written your IF
> THEN ELSE example as:
>
>    IF t DIV 32 = 0 THEN
>      IF t IN {7, 9..10} THEN
>        t := 11
>      ELSIF t IN {13, 14..16} THEN
>        t := 12
>      END
>    END;
>
> Which is only 32 instructions using your same method of counting.
>
> If (as in your example) you knew for sure that t was in the range of 0..31
> you wouldn't need the initial DIV statement either,
>
> Regards,
> Chris Burrows
> CFB Software
> http://www.astrobe.com
>
>
> >
> > From: Oberon [mailto:oberon-bounces at lists.inf.ethz.ch] On Behalf Of
> > Jan de Kruyf
> > Sent: Friday, 27 November 2015 2:04 AM
> > To: ETH Oberon and related systems
> > Subject: Re: [Oberon] Numerical CASE Statements in Project Oberon
> >
> > Here is some news:
> >
> > We get cleanly compiling code.
> >
> > With this test module:
> > -------
> > MODULE TestIf;
> > VAR t : INTEGER;
> >
> > BEGIN
> >    t := 10;
> >    IF ((t >= 9) & (t <= 11)) OR (t = 7) THEN
> >       t := 11;
> >    ELSIF (t = 13) OR ((t >= 14) & (t <= 16)) THEN
> >       t := 12
> >    END;
> >
> >    CASE t OF
> >      9 .. 11, 7  : t := 11;
> >    |13, 14 .. 16 : t := 12
> >    END;
> >
> > END TestIf.
> > -----------
> >
> > When I only compile the IF structure I get 37 assembly instructions,
> > average seek for named values is 13.66 instruction times.
> > When I only compile the CASE structure I get 40 assembly
> > instructions, average seek for named values is 7.33 .
> > (this is from doing a hand count through the search structure)
> >
> > A lot of waste in the IF is generated by reloading the 't' variable
> > for every compare, while I steal a register to keep 't' loaded.
> >
> > j.
> >
> >
> > On Tue, Nov 24, 2015 at 8:38 PM, Jan de Kruyf
> > <jan.de.kruyf at gmail.com> wrote:
> > John, thats a complex matter really.
> >
> > Anything we dont know at compiletime is left dangling for resolving
> > 'later'.
> > Part of that 'later' is resolved by the linker, in Linux or Windows.
> > And still more is resolved when the code gets loaded.
> >
> > In Oberon, in general there is no linker, except when we want to
> > build some boot-code.
> >
> > Everything not known at compile-time must then be fixed up when we
> > load the module. And to complicate matters, some choices are made by
> > the system designer about what we actually _want_ to know at compile
> > time. It is basically a cost / benefit choice, sometimes it is easier
> > to leave the complete solution until load time, although at least
> > part of the knowledge was available at compile-time.
> >
> > In the case I queried I did not see a reference to the index register
> > that LDR uses. That space as left at '0' to be patched at load-time
> > (so it looked as if R0 was to be used for an index), although R12,
> > the standard index register, could have been written there at
> > compile-time for my specific code.
> >
> > Section 6.3 gives some small introduction to the art of loading. Near
> > the end of the page is the line:
> > "At the very end of the file three integers called fixorgP, fixorgD,
> > and fixorgT are read."
> > That is where he talks about the patching.
> >
> > From the code in Modules.Load and from the compiler description it
> > follows that globals need to be treated specially, since they might
> > come of any module. So although we might have a partial knowledge of
> > the place of a 'local' global at compile time, it is obvious that we
> > don't know at all about globals in other modules. So Wirth chose to
> > fix them all in one place: the module loader.
> >
> > In any case: a good way to learn compilers is to target a small micro
> > controller that you know very well, and adapt the Oberon 0 compiler.
> > I have done it many years ago for an 8 bit AVR, and it has helped me
> > ever since.
> >
> > Cheers,
> >
> > j.
> >
> >
> > On Tue, Nov 24, 2015 at 1:22 PM, John Stout <JSS at kgv.ac.uk> wrote:
> > Jan
> >
> > Yes, that's the one although my copy is on faded line printer paper!
> >
> > I'm interested in your email about code generation: what does
> > Module.Load patch and to what?
> >
> > I've just bought an OberonStation and am getting to grips with it. I
> > think the first task is to get another nRF24L01+ system working so
> > that I can transfer stuff to and from it.
> >
> > John
> >
> >
> > ---------------------------------------------------------------------
> > -
> >
> > Message: 1
> > Date: Mon, 23 Nov 2015 12:09:45 +0200
> > From: Jan de Kruyf <jan.de.kruyf at gmail.com>
> > To: ETH Oberon and related systems <oberon at lists.inf.ethz.ch>
> > Subject: Re: [Oberon] Numerical CASE Statements in Project Oberon
> > Message-ID:
> >         <CAA85NCh6R8Xf-Tp53sFF0=F_5rnH7WXoeTyeDQss-
> > eDMsVMaLg at mail.gmail.com>
> > Content-Type: text/plain; charset="utf-8"
> >
> > Is it this one John?
> >
> > http://homepages.cwi.nl/~steven/pascal/
> >
> > There are links there to a 76 version from eth.
> >
> > j.
> >
> >
> > On Mon, Nov 23, 2015 at 9:47 AM, John Stout <JSS at kgv.ac.uk> wrote:
> >
> > > Well, I should have done a bit more research before making my
> > comments,
> > > and/or done all the exercises in Compiler Construction, which would
> > have
> > > lead me to Professor Wirth's preferred implementation for CASE.
> > >
> > > I have the source code for the Pascal P4 compiler from 1976
> > (courtesy of
> > > Lancaster University) and that uses this system, although it does
> > place a
> > > maximum of 1000 on the number of cases.
> > >
> > > John
> >
> > [King George V Logo]
> > John Stout
> > Management Information Systems Coordinator
> > Tel: 01704 530601
> > E-Mail: JSS at kgv.ac.uk
> > Web: www.kgv.ac.uk
> >
> >
> > Information contained in this e-mail is intended for the use of the
> > addressee only and is confidential.  Any dissemination, distribution,
> > copying or use of this communication without prior permission of the
> > addresseeis strictly prohibited.
> >
> > Every effort has been made to ensure that any attachment to this mail
> > does not contain virus. King George V College has taken every
> > reasonable precaution to minimise this risk, neither it nor the
> > sender can accept liability for any damage which you sustain as a
> > result of software viruses. You should carry outyour own virus checks
> > before opening any attachments.
> >
> > [Think Before You Print]
> > --
> > Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related
> > systems
> > https://lists.inf.ethz.ch/mailman/listinfo/oberon
> >
>
>
> --
> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
> https://lists.inf.ethz.ch/mailman/listinfo/oberon
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.inf.ethz.ch/pipermail/oberon/attachments/20151128/1a8b2811/attachment.html>