[Oberon] Numerical CASE Statements in Project Oberon

[Chris Burrows]

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
>