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.