<div dir="ltr">Hallo John (again)<div><br></div><div>I finally read your code properly, it looks quite good. And it is easily build without writing a compiler section for it</div><div>by using hi level IF THEN etc. It will give the same code I am sure, from what I read in the present compiler.</div><div><br></div><div>So we can have a shoot out and get some statistics I would say :) since your case selection will be very slightly faster for very small case statements., or where there is a skew to the very low end of the range of labels.</div><div><br></div><div>Other than that I diligently read the Project Oberon book just now on the matter, since you claim to speak for the master. But I found that in the O-2 compiler he made as big a mess building a jump table, as I do building a bin tree. On top of it he limits himself of necessity to 128 case constants / ranges while I am theoretically unlimited. (not that it will ever make a difference of course) But at that kind of sizes his should run much faster, and probably on average eat more program memory.</div><div><br></div><div>cheers,</div><div><br></div><div>j.</div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Nov 19, 2015 at 4:10 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>
I wasn't suggesting that we NOT implement it, just that compiling it (implementing it) to a<br>
series of compiled IF THEN statements may be more in keeping with NW's view.<br>
<br>
Suppose we have (taken from the Oberon-07 report):<br>
<br>
CASE k OF<br>
 0: x := x + y<br>
 | 1: x := x − y<br>
 | 2: x := x * y<br>
 | 3: x := x / y<br>
END<br>
<br>
This would compile, using IF THEN equivalents, to code like this (I've assumed that R14 is a base register):<br>
<br>
LDR0, R14, k_offset<br>
SUBR1, R0, 0<br>
BNECase_1<br>
code for x := x + y<br>
BEnd_Case<br>
Case_1:<br>
SUBR1, R0, 1<br>
BNECase_2<br>
Code for x := x - y<br>
BEnd_Case<br>
Case_2:<br>
SUBR1, R0, 2<br>
BNECase_3<br>
Code for x := x * y<br>
BEnd_Case<br>
Case_3:<br>
SUBR1, R0, 3<br>
BNEEnd_Case<br>
Code for x := x / y<br>
End_Case:<br>
<br>
This is simple and clear. There is a clear maximum execution path length. Adding label ranges is a bit longer, but still (I think) simple and clear, e.g.,<br>
<br>
CASE k OF<br>
0 .. 10: x := x − y<br>
 | 11 .. 1000: x := x * y<br>
 | 1001 .. 2047 : x := x / y<br>
END<br>
<br>
could compile to something like this:<br>
<br>
LDR0, R14, k_offset<br>
SUBR1, R0, 0<br>
BLTCase_1<br>
SUBR1, R0, 10<br>
BGTCase_1<br>
code for x := x - y<br>
BEnd_Case<br>
Case_1:<br>
SUBR1, R0, 11<br>
BLTCase_1<br>
SUBR1, R0, 1000<br>
BGTCase_2<br>
Code for x := x * y<br>
BEnd_Case<br>
Case_2:<br>
SUBR1, R0, 1001<br>
BLTCase_1<br>
SUBR1, R0, 2047<br>
BNEEnd_Case<br>
Code for x := x / y<br>
End_Case:<br>
<br>
This will work even for very large ranges. The size of the generated code (no data needed) depends on the number of cases, not the range of the constants in the case label list or case label range.<br>
<br>
Adding label lists:<br>
<br>
CASE k OF<br>
0, 10: x := x − y<br>
 | 11, 1000: x := x * y<br>
 | 1001, 2047, 19 : x := x / y<br>
END<br>
<br>
could compile to something like this:<br>
<br>
LDR0, R14, k_offset<br>
SUBR1, R0, 0<br>
BEQC_1<br>
SUBR1, R0, 10<br>
BNECase_1<br>
C_0:code for x := x - y<br>
BEnd_Case<br>
Case_1:<br>
SUBR1, R0, 11<br>
BEQC_1<br>
SUBR1, R0, 1000<br>
BNECase_2<br>
C_1:Code for x := x * y<br>
BEnd_Case<br>
Case_2:<br>
SUBR1, R0, 1001<br>
BEQC_3<br>
SUBR1, R0, 2047<br>
BEQC_3<br>
SUBR1, R0, 19<br>
BNEEnd_Case<br>
C_3:Code for x := x / y<br>
End_Case:<br>
<br>
John<br>
<span class=""><br>
>> Am 16.11.2015 um 09:31 schrieb Jan de Kruyf <<a href="mailto:jan.de.kruyf@gmail.com">jan.de.kruyf@gmail.com</a>>:<br>
>><br>
>> Yes,<br>
>> The old man has been right most of the time, I agree. And I will have<br>
>> a royal battle to reduce the compiler construction back down to<br>
>> Wirthian elegance, that I also realize. But at the same time the code<br>
>> I produce is very elegant and sweet. On the basis of that I would say<br>
>> you are wrong in your statement that IF THEN can be made as efficient<br>
>> as a good case construct. Besides, a Case statement allows ranges<br>
>> like A..Z, a..z and so on, this has never been part of IF THEN, while<br>
>> in a properly constructed bin-tree it resolves itself.<br>
>><br>
>> So since Wirth was first and foremost a teacher all his life, we<br>
>> could say that there are 2 learning opportunities here 1. to produce<br>
>> fast code.<br>
>> 2. to construct an elegant way of doing so.<br>
>><br>
>>  I think that the master himself also realized the issues you and I<br>
>> are bringing up, and did not see his way out of the predicament yet.<br>
</span><span class="">>> And since he is about 80 now and since he still got a few irons in<br>
>> the fire this was left for a bit.<br>
>><br>
</span><span class="">>> Lastly Dijkstra taught that you should never limit yourself because<br>
>> of inefficient machines. But you should strive to generalize any<br>
>> language design solution to as many cases as possible, even if that<br>
>> slows your program execution down a bit. There were big arguments in<br>
>> the Algol design meetings about that. Some people then felt that you<br>
>> had to live with the equipment given and use it as efficiently as<br>
>> possible. Wirth no doubt knows that whole history even better than I<br>
>> do. In the mean time of course, the machine limitations of those days<br>
>> (it was the time of the vacuum tubes) have been solved a hundred<br>
>> times over, but we still are trying to live with the language limitations of some of the older languages.<br>
>> Ergo the numerical case statement is in the O-7 language report, but<br>
>> is has not been implemented yet.<br>
>><br>
>> So I feel fully justified implementing it. The way how to, we can<br>
>> talk about. If the Oberon community is alive and well ten I am sure<br>
>> that the last word has not been spoken yet.<br>
>><br>
>><br>
>> Enjoy your day<br>
>><br>
>> j.<br>
>><br>
<br>
</span>[King George V Logo]<br>
<span class="">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 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>
</span>[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 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>