Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!bloom-beacon!ardent.UUCP!jkh
From: jkh@ardent.UUCP
Newsgroups: comp.windows.x
Subject: Re: xterm/charproc.c
Message-ID: <8806290527.AA10501@sim.ardent.com>
Date: 29 Jun 88 05:27:35 GMT
References: <58279@sun.uucp>
Sender: daemon@bloom-beacon.MIT.EDU
Organization: The Internet
Lines: 41

>Because any reasonable C compiler should be able to detect that this is a
>"dense" case statement and generate equally efficient code regardless of the
>order of the "case" statements (that is, it should generate a range check
>followed by an indexed jump of some sort).  Our 68K and SPARC compilers, at

Yes, I realize this. However, "reasonable" C compilers aren't always
available and we all know how blindingly quick most compiler groups
are at responding to things like this. The intention was merely to
provide a free optimization to those unfortunates still stuck with
simplistic compilers. Ardent's C compiler is not guilty of this, but
some others are. It's also important to note that it's often undesirable
(particularly in the case of xterm) to have everyone running an optimized
binary if the system is less than stable and you want to be able to do
something useful with the core files that xterm leaves behind. A number
of systems at UCB don't compile xterm or the X libraries with -O.

When this is the case, Sun's 3.4 C compiler produces a linear list
of compares:


L28:
        movl    #0x15,a6@(-0x8)
        jra     L14
L29:
        movl    #0x15,a6@(-0x8)
        jra     L14
L30:
        movl    #0x15,a6@(-0x8)
        jra     L14
...

L14:
        movl    a6@(-8),sp@-
        pea     L37
        jbsr    _printf
        addqw   #8,sp
        unlk    a6
        rts


For case statements containing well over 40 elements.