<div dir="ltr"><div>Hallo Chris,</div><div>Thanks you for your answer</div><div><br></div>> Don't even think about implementing it unless you are planning to do it properly - <br><div><br></div><div>Didnt read anything like that in the License :)</div><div>Perhaps say "I will not even think of using it, or voting for it -"</div><div><br></div><div>If that is what you meant: you are most welcome, ha ha.</div><div><br></div><div>Now for more serious matters:</div><div><br></div><div>I have constructed smallish compilers before. I do understand the flow of the O7 Risc compiler. I have not done a CASE construction before, but I do understand the different ways of doing it.</div><div><br></div><div>You might have noticed that I like to work in public, mostly because my brain is not as nimble any more as it once was, so every extra pair of eyes helps. So if I am going to do this I would expect lots of sound input, like yours,  from the community. I am sure that in that way most issues will be gracefully resolved.</div><div><br></div><div>> RISC6 <br></div><div>Pray, send me the documentation. By the way, I feel seriously limited in any Oberon environment by the fact that nobody uses a version control system. I do not find that conductive to clean working. Finding something is forever a hit and miss game.</div><div><br></div><div>> constant performance</div><div>I am aware of </div><div>a. a direct jumptable</div><div>b. a binary search in the jump table</div><div>c. hashing the index.</div><div>d. combinations of those to be decided upon at compile time.</div><div><br></div><div>For the time being I was getting my stuff together for item b. -- c. is often more trouble than it is worth and a. makes for a big table in the case of a range.  But perhaps I might consider making a combination of a and b. I have not finished my think or gotten enough input from the community yet. </div><div><br></div><div>> However, if constant performance overhead is . . .</div><div>Sure there are many ways to do things, I was triggered by the elegance and ease of the CASE statement. I have often used it in preference to anything else, for clarity.</div><div><br></div><div><div>> I can't see anywhere in the report that states that "when not all cases are catered for . . .<br></div></div><div>That statement should have been thought through a bit more.</div><div>In any case:</div><div>The green book (O-2) says  (A.5.9) </div><div>. . . . the symbol ELSE is selected, if there is one. Otherwise it is considered as an error.</div><div><br></div><div>i.e I would suspect a trap at runtime if a CASE was not resolved and there was no ELSE.</div><div><br></div><div>In Ada all possible values of the input variable must be covered in the CASE statement (including the optional ELSE), otherwise the compiler will complain. (Remember in Ada a type can have a range of valid values specified, this is not so in Oberon)</div><div>So in other words: the ELSE statement would be a way of complaining gracefully that the CASE is not complete, or that there is an exceptional condition, as we also often use it in an IF THEN construct.</div><div><br></div><div>A partial parse of an Oberon source file comes to mind:</div><div><br></div><div>CASE sym OF</div><div>a : ...</div><div>| b : ...</div><div>| c : ...</div><div>else</div><div>     GetSym;</div><div>END;</div><div> </div><div>At the moment (in the absence of a numerical case) this type of construct is handled by IF THEN ELSE in the O-7 compiler.</div><div><br></div><div><br></div><div>> but that is all I can think of for now,<br></div><div>Thanks again for your input. And I am sure other people will also have something to contribute here.</div><div><br></div><div>Cheers,</div><div><br></div><div>j.</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Nov 7, 2015 at 3:03 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">><br>
> From: Oberon [mailto:<a href="mailto:oberon-bounces@lists.inf.ethz.ch">oberon-bounces@lists.inf.ethz.ch</a>] On Behalf Of<br>
> Jan de Kruyf<br>
> Sent: Friday, 6 November 2015 8:37 PM<br>
> To: Paul Reed; ETH Oberon and related systems<br>
> Subject: Re: [Oberon] RISC.img<br>
><br>
> 2. Question:<br>
> I see that the 'numerical' CASE implementation is missing in ORP.Mod,<br>
> although it is in the language spec and although we might reasonably<br>
> expect people to port programs from O2 to O7.<br>
><br>
> Would it be in the interest of the community for me to try and<br>
> implement that part, at least for constant labels?<br>
><br>
<br>
Don't even think about implementing it unless you are planning to do it properly - a half-baked solution would be worse than none. e.g. I would expect a complete solution to include the implementation of a RISC6 (or RISC5.1 maybe?) processor which has indexed-branch statements.<br>
<br>
> I am aware that 1. a table driven CASE might take up some codespace<br>
> and 2. that coding it as an IF THEN ELSIF THEN will bring no speed<br>
> advantage. But at the same time there are many instances where a CASE<br>
> statement is easy to write and convenient to read.<br>
><br>
<br>
Apart from 'convenience' an advantage of table-driven CASE over IF THEN ELSIF is that each case usually has a constant performance overhead - there is no preferential treatment for any of the cases. This contrasts with IF THEN ELSIF ladders where it takes longer to reach statements at the end to execute them than those at the beginning.<br>
<br>
However, if constant performance overhead is a requirement it does not necessarily need the existence of a 'numerical' CASE. Another possible way of achieving a constant performance overhead with Oberon is to use an array of procedures where each array element corresponds to each case label.<br>
<br>
><br>
> 3. Question:<br>
> Why does the numerical CASE have no ELSE part anymore in O7. It is a<br>
> very convenient error catcher. (i.e. when not all cases are catered<br>
> for, the program does not silently fall through without warning.)<br>
><br>
<br>
I can't see anywhere in the report that states that "when not all cases are catered for, the program silently falls through without warning". That is not necessarily a correct assumption - one alternative possibility might be to raise an error. Other error-handling behaviour including how to handle duplicate labels, descending ranges etc. etc. would also need to be specified for a complete solution. Implementation limits would also need to be specified e.g. minimum / maximum value of labels etc.<br>
<br>
There might be other considerations but that is all I can think of for now,<br>
<br>
Regards,<br>
Chris<br>
<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>
<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>
</blockquote></div><br></div>