This is the mail archive of the
mailing list for the GCC project.
Re: Faster compilation speed
- From: Tim Josling <tej at melbpc dot org dot au>
- To: gcc at gcc dot gnu dot org
- Date: Wed, 14 Aug 2002 07:59:49 +1000
- Subject: Re: Faster compilation speed
- Organization: Melbourne PC User Group
>>File size is not the only parameter. Modern languages do more
>> complicated thing than the average Cobol compiler I suppose....
> You suppose dramatically wrong (it is amazing how little people now about
> COBOL and how much they are willing to guess). Modern COBOL is an extremely
> complex language, certainly more complex than Ada, and probably more complex
> than C++.
The COBOL spec is about 1500 pages in a smallish font (including addenda and
the "intrinsic functions"). My copy of the C standard, for example, runs to
about 200 pages(1). 'Modern' languages are a lot more regular and were
designed with the compiler writer in mind. The concerns of the compiler writer
were definitely not at the forefront of the COBOL language designers' minds.
> The point is that GCC has a really terrible time if you throw a single
> procedure with tens of thousands of lines of code in it at the compiler.
Correct. The largest single function written in COBOL, that I have been able
to find, is several *hundred thousand* lines long. Even the slightest
non-linearity is a major problem.
(1) Excluding the library. You could argue that the some COBOL verbs are
similar to the library, which is true, but the C library hardly affects the
compiler itself. In GNU the C library is even a separate project. In COBOL the
verbs are part of the language syntax and require their own parse trees and so
forth so it would be very difficult to have a separate project. Even the
intrinsic functions though they look like functions are just more syntax in a
slightly more regular form.
Some of the C library functions are tightly coupled to the compiler e.g.
setjmp, va_*, memset (if inlined), printf (for parameter checking). But by and
large the library is independent.