Re: lcc intel backend?

nick@nsis.cl.nec.co.jp (Gavin Thomas Nicol)
Tue, 12 Oct 1993 23:35:20 GMT

          From comp.compilers

Related articles
lcc intel backend? nick@nsis.cl.nec.co.jp (1993-10-07)
Re: lcc intel backend? wjw@eb.ele.tue.nl (1993-10-11)
Re: lcc intel backend? cwf@research.att.com (1993-10-12)
Re: lcc intel backend? nick@nsis.cl.nec.co.jp (1993-10-12)
Re: lcc intel backend? compile time? rds95@csc.albany.edu (1993-10-13)
Re: lcc intel backend? dobrien@seas.gwu.edu (1993-10-15)
Re: lcc intel backend? pcg@aber.ac.uk (1993-10-18)
Re: lcc intel backend? anton@mips.complang.tuwien.ac.at (1993-10-19)
| List of all articles for this month |

Newsgroups: comp.compilers
From: nick@nsis.cl.nec.co.jp (Gavin Thomas Nicol)
Keywords: C, 386
Organization: Compilers Central
References: 93-10-041 93-10-050
Date: Tue, 12 Oct 1993 23:35:20 GMT

>wjw@eb.ele.tue.nl (Willem Jan Withagen) writes:
>Other people might differ on this, but as soon I you said free Unix I
>don't consider size of much importance for compilers. And my guess is that
>the code generator part of gcc isn't taking an abnormal piece of the code.
>If you are considering MessyDos (aka. interrupt-handler) then you have a
>point, but even there are extenders available which also you to run BIG
>programs in flat space. Even on my old and lowly 386/DX 20Mhz, no cache
>box, was I pleased with Emx/Gnu's performance. So why are you asking this?


Well, gcc is a fine compiler (I'm using it, of course), but:


1) It takes up a large amount of disk space. Also executable size
      can slow down compiles (because it is repeatedly loaded from disk,
      though this is system dependent).


2) It is slow, even with optimisation turned off (though code
      generation tends to be good).


3) It uses a lot of memory, especially with optimisation and inline
      function usage. This causes systems with small amounts of memory
      to swap a lot.


I should note that from the lcc papers I've read, it seems like it is much
faster, and much smaller than gcc, but code generation is not as good.
This makes it ideal for the development stages where fast compile times
are more important than good code (in general). My request is based on
this, and the above 3 points.
--


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.