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