<div dir="ltr">Here is some news:<div><br></div><div>We get cleanly compiling code.</div><div><br></div><div>With this test module:</div><div>-------</div><div><div>MODULE TestIf;</div><div>VAR t : INTEGER;</div><div><br></div><div>BEGIN</div><div> t := 10;</div><div> IF ((t >= 9) & (t <= 11)) OR (t = 7) THEN</div><div> t := 11;</div><div> ELSIF (t = 13) OR ((t >= 14) & (t <= 16)) THEN</div><div> t := 12</div><div> END;</div><div> </div><div> CASE t OF </div><div> 9 .. 11, 7 : t := 11;</div><div> |13, 14 .. 16 : t := 12</div><div> END;</div><div><br></div><div>END TestIf.</div></div><div>-----------</div><div><br></div><div>When I only compile the IF structure I get 37 assembly instructions, average seek for named values is 13.66 instruction times.</div><div>When I only compile the CASE structure I get 40 assembly instructions, average seek for named values is 7.33 .<br></div><div>(this is from doing a hand count through the search structure)</div><div><br></div><div>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.</div><div><br></div><div>j.</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Nov 24, 2015 at 8:38 PM, Jan de Kruyf <span dir="ltr"><<a href="mailto:jan.de.kruyf@gmail.com" target="_blank">jan.de.kruyf@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">John, thats a complex matter really.<div><br></div><div>Anything we dont know at compiletime is left dangling for resolving 'later'.</div><div>Part of that 'later' is resolved by the linker, in Linux or Windows. And still more is resolved when the code gets loaded.</div><div><br></div><div>In Oberon, in general there is no linker, except when we want to build some boot-code.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>Section 6.3 gives some small introduction to the art of loading. Near the end of the page is the line:</div><div>"At the very end of the file three integers called fixorgP, fixorgD, and fixorgT are read."</div><div>That is where he talks about the patching.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>Cheers,</div><div><br></div><div>j.</div><div><br></div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Nov 24, 2015 at 1:22 PM, John Stout <span dir="ltr"><<a href="mailto:JSS@kgv.ac.uk" target="_blank">JSS@kgv.ac.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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 Module.Load patch and to what?<br>
<br>
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.<br>
<br>
John<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" target="_blank">jan.de.kruyf@gmail.com</a>><br>
To: ETH Oberon and related systems <<a href="mailto:oberon@lists.inf.ethz.ch" target="_blank">oberon@lists.inf.ethz.ch</a>><br>
<span>Subject: Re: [Oberon] Numerical CASE Statements in Project Oberon<br>
</span>Message-ID:<br>
<CAA85NCh6R8Xf-Tp53sFF0=<a href="mailto:F_5rnH7WXoeTyeDQss-eDMsVMaLg@mail.gmail.com" target="_blank">F_5rnH7WXoeTyeDQss-eDMsVMaLg@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<div><div><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" target="_blank">JSS@kgv.ac.uk</a>> wrote:<br>
<br>
> Well, I should have done a bit more research before making my comments,<br>
> and/or done all the exercises in Compiler Construction, which would 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 (courtesy of<br>
> Lancaster University) and that uses this system, although it does 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" target="_blank">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 addressee only and is confidential. Any dissemination, distribution, copying or use of this communication without prior permission of the addresseeis strictly prohibited.<br>
<br>
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.<br>
<br>
[Think Before You Print]<br>
--<br>
<a href="mailto:Oberon@lists.inf.ethz.ch" target="_blank">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>
</div></div></blockquote></div><br></div>