|lcc intel backend? email@example.com (1993-10-07)|
|Re: lcc intel backend? firstname.lastname@example.org (1993-10-11)|
|Re: lcc intel backend? email@example.com (1993-10-12)|
|Re: lcc intel backend? firstname.lastname@example.org (1993-10-12)|
|Re: lcc intel backend? compile time? email@example.com (1993-10-13)|
|Re: lcc intel backend? firstname.lastname@example.org (1993-10-15)|
|Re: lcc intel backend? email@example.com (1993-10-18)|
|Re: lcc intel backend? firstname.lastname@example.org (1993-10-19)|
|From:||email@example.com (Gavin Thomas Nicol)|
|Date:||Tue, 12 Oct 1993 23:35:20 GMT|
>firstname.lastname@example.org (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.
Return to the
Search the comp.compilers archives again.