Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!husc6!spdcc!ftp!wjr From: wjr@ftp.COM (Bill Rust) Newsgroups: comp.lang.c Subject: Re: forward references in typedefs Message-ID: <686@ftp.COM> Date: 25 Jul 89 14:27:52 GMT References: <55480@tut.cis.ohio-state.edu> <1989Jul20.152935.14872@utzoo.uucp> <24CB9E07.9547@marob.masa.com> <18729@mimsy.UUCP> Reply-To: wjr@ftp.UUCP (Bill Rust) Organization: FTP Software, Inc. Lines: 33 In article <18729@mimsy.UUCP> chris@mimsy.UUCP (Chris Torek) writes: >In article <24CB9E07.9547@marob.masa.com> cowan@marob.masa.com (John Cowan) >writes: ||... As someone (Chris Torek?) said earlier in this group, "all 'struct' ||pointers must 'smell' the same." If this behavior is not guaranteed, ||forward references to structs would be unimplementable in one pass. | |It was Doug Gwyn, but this is otherwise correct. | ||Ufcawss, if you talk to the people who wrote VMS C, they'll tell you that ||all one-pass implementations of C are unacceptable! (This has something to ||do with generating good code for the 'switch' statement.) | |They are both right and wrong. One-pass code generation means there |are few opportunities for optimsiation; but generating good switches |is easy. Simply emit a branch at the top of the switch, code at each |of the labels, a branch at the bottom, and then generate the code |that actually implements the switch. E.g., given | | [Clever example deleted] Excuse me. I am not a compiler writer but even I know that there are two ways to implement switches: jump tables and compare and execute when equal. Jump tables (ie jmp switch_list[ix] where ix is some easy transformation of the switch variable) are much more efficient when the range of values that the switch variable can assume is limited (ie switch variable in range of 1 to 20 and it assumes 75% of values). The only way to tell if a jump table is better than compare and jump is to see what the range of the switch variable is and how many values it actually assumes. This is very difficult to do in a one pass compiler. The previous correspondent completely ignored this in his response. Bill Rust (wjr@ftp.com)