[Oberon] A CASE quiz

Jörg joerg.straube at iaeth.ch
Fri Feb 16 13:07:02 CET 2018


Okay. “Q” and ”T” are not mentioned and will be trapped.

If you know that for ”Q” and “T” the value should be 0 then why not mention
them explicitly.

 

“CASE” is meant as an implementation optimization with a jump table instead
of several IFs.

With a jump table you have the in-table cases and the out-of-table case.

 

Should ELSE cover both or only in-table or only out-of-table?

 

We really have to see, how many of us did detect that the numeric CASE is
not implemented (yet) in ORP.Mod?

I assume there is only a handful (either me as being interested in compiler
construction or the very few actually trying to use numeric CASE)

 

A word to speed benefit: Even if you have - let’s say - 128 case labels you
would need only 7 IFs at runtime (with binary division).

So, the benefit of having a jump table is rather small.

Don’t get me wrong: numeric CASE is nice and syntactically pleasing, but how
often do you need it?

 

br

Jörg

 

 

From: Oberon [mailto:oberon-bounces at lists.inf.ethz.ch] On Behalf Of Chris
Burrows
Sent: Friday, February 16, 2018 12:36 PM
To: ETH Oberon and related systems <oberon at lists.inf.ethz.ch>
Subject: [Oberon] A CASE quiz

 

I have attached two copies of a CASE statement which implements part of the
Soundex algorithm. Assume that both compile OK but both have at least one
identical logical error which you may not have noticed if I hadn’t warned
you. Which version do you think would be more effective in flushing  out the
error if the programmer was not aware of his mistake?

 

I put my money on the one without the ELSE 


 

Regards,

Chris Burrows

 

CFB Software

http://www.astrobe.com/RISC5

 

 

 

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.inf.ethz.ch/pipermail/oberon/attachments/20180216/d24a0e49/attachment.html>


More information about the Oberon mailing list