1Re: Yes, they are special, but...0

[Barry Margolin <barmar@THINK.COM>]

    Date: Mon, 19 Jun 89 12:42 PDT
    From: TYSON@warbucks.ai.sri.com (Mabry Tyson)

    Latex:  We run a version that is derived from a Pascal-to-Lisp
    translator that was developed by Art Flatau.  It is somewhat faster (2x,
    I think I recall) than the one that is run through the Pascal compiler.
    In looking at where the time was taken in the inner loop, there is one
    statement that is a big case statement (the kind where the next
    instruction is gotten by adding the index to the PC).  In Lisp, it was
    a COND and so potentially did a lot more work.  But that is one
    instruction that was not in the 3600 (I haven't looked at the Ivory)
    instruction set that would have sped this program up somewhat.
    In any case, I don't think the Pascal compiler is responsible for more
    than about a 2x slowdown.  (Probably less, as I changed some macros to
    make certain assumptions about the code that I knew to be true.)

If the CASE statement you're talking about looks something like

	(case <expression>
	  (0 ...)
	  (1 ...)
	  ...
	  (t ...))

then the 3600 compiler will compile this into a computed go (I believe
this was introduced in Genera 7.1 or 7.2).  It does this when all the
keys are non-negative integers and the key space isn't too sparse (more
than half of the keys from 0 to the largest key are used).  The only
complaint I have is that it isn't smart about key ranges that start far
from 0; i.e. it won't optimize

	(case <expression>
	  (100 ...)
	  ((101 102 103) ...)
	  (104 ...)
	  (105 ...))

because it looks like a sparse key set (6 keys out of the range [0
100]); it should optimize it as it would

	(case (- <expression> 100)
	  (0 ...)
	  ((1 2 3) ...)
	  (4 ...)
	  (5 ...))

The same strategy would also permit negative keys.  It turns out that
this change requires three trivial changes to one function
(CLI::L-CASE-TO-COMPUTED-GO).

                                                barmar