Re: Using C as a back end

Im Artikel 00-10-234, "Joachim Durchholz" <joachim_d@gmx.de>
schreibt:


>OTOH when compared to, say, Turbo Pascal, half a minute for
>recompiling just a few thousand lines of code is still ridiculously
>slow. I compiled 100.000s of lines in a minute on a 16-MHz machine
>years ago, it should be a snap on today's multi-100MHz machines. I
>don't know what's eating up all this time; there are two potential
>sources: 1) Language differences 2) Optimization


I have outlined the according problems many times, but I'll add my 2c once
again:


In Pascal every unit has a fixed interface, which must be parsed only once.
Afterwards that compiled interface can be referred to in any other unit,
without any future parsing of the "used" module.


In C the nesting of the #included header files can be different for every
module, and the same header file can be invoked multiply, with different
conditions (settings of the preprocessor... symbols). Therefore every #include
statement *must* result in another parse of the header file and all of it's
#included files.


The "precompiled" headers must not only track the sequence of directly
#included files, but also must track the settings of all symbols, with every
#include. When another #include is found, then a test is required, whether the
requested header file was #included already within a known environment, where
the environment consists of all defined and undefined symbol values. You can
imagine how expensive such a check of the environment can be, with a look at
all those #defines, typedefs and other declarations in your header files.


Finally an example, to hopefully clarify the complexity of the environment:


#if CondX == 0
    typedef Tx...
    #define MacroZ ...
#elif CondY...
    typedef Tx...
    #define MacroZ ...
#else
    #define CondX 1
    #undef CondY
    #define MacroZ ...
#endif
Tx v1, v2, MacroZ(...), ...


Here the symbols Tx, MacroZ, CondY, and consequently the type of v1, v2 etc.
can depend on any number of preconditions, and these #defines, definitions and
typedefs remain valid even after leaving this module or header file. That's why
it's easier and (in most cases) faster to parse the #included files once more,
instead of checking whether the definition of every single definition is
equivalent to the definition in some other (known) context.


DoDi
[There are some fairly simple heuristics that identify most of the cases where it's
safe to skip rereading an included file, but I agree that it's a mess. -John]

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