Date: Sun, 11 Jun 95 00:32:26 -0700 From: Bakul Shah <bakul@netcom.com> To: Bruce Evans <bde@zeta.org.au> Cc: hackers@freebsd.org Subject: Re: Slight flame from Linux user Message-ID: <199506110732.AAA14228@netcom13.netcom.com> In-Reply-To: Your message of "Sun, 11 Jun 95 15:07:27 %2B1000." <199506110507.PAA30145@godzilla.zeta.org.au>
next in thread | previous in thread | raw e-mail | index | archive | help
I'll shut up about this topic after this message. > My compiler is much smaller, compiles much faster, and generates only slightly > worse code -- but I won't touch it :-). I will, if I can have a copy of your compiler :-) > I ran a stupid benchmark: ... > [z.c is essentially 32768 lines `i=1;' where `i' is auto int. rcc is > the main stage of lcc. It must be doing something strange for the > user+sys times not to add up to nearly the real time and bad buffering > for the system time to be so large.] Yeah, there are a number of places where lcc can be tuned. But note that on realistic examples it does much better. time $(CC) -DHAVE_CONFIG_H -o cproto cproto.c lintlibs.c semantic.c strkey.c strstr.c symbol.c y.tab.c -lfl 26.672s real 18.216s user 3.193s system 80% CC=lcc 46.399s real 36.016s user 3.969s system 86% CC=gcc-2.4.5 50.239s real 37.367s user 4.757s system 83% CC=gcc-2.6.3 67.093s real 48.755s user 4.561s system 79% CC=gcc-2.6.3 -O size cproto text data bss dec hex 45056 16384 1480 62920 f5c8 lcc 61440 4096 0 65536 10000 gcc-2.4.5 65536 4096 0 69632 11000 gcc-2.6.3 53248 4096 0 57344 e000 gcc-2.6.3 -O I picked cproto at random but this is true for most programs. > We also need support for asm, inline, -fpic, a standard assembler, ... To replace the default compiler we need these. But surely not for adding another compiler in the ports directory. > > including lcc without modification in another distribution is OK. > This doesn't help. You have to modify it to support long long... I think shipping a diff file would not violate the terms. To summarize: I agree that lcc copyright needs to be clarified, it lacks certain gcc extensions we depend on so it can't be used as the default compiler, it does not generate as good code as gcc (with -O or -O2) and it has some rough edges (not unlike early gcc). On the positive side it runs about twice as fast, its code is only about 10% slower (compared to gcc -O compiled code), it is easier to understand and it is described in great detail in one of the best compiler books in recent times (destined to be a classic IMHO), it forces you to stick to ANSI C, it seems to be more robust, and I think it is a better vehicle for adding further improvements. On the balance `touching it' has been a pleasant experience. -- bakul
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199506110732.AAA14228>