Re: Using C as a back end

Randall Hyde wrote:
> Joachim Durchholz at joachim_d@gmx.de wrote on 10/31/00 12:43 PM:
> > [On 1) Language differences, 2) Optimization]
> > I don't think that (1) is responsible for many differences; C
> > doesn't have anything that Pascal has. If anything, then Pascal
> > is a bit more difficult to generate code for (it's got nested
> > functions), but that's nothing that should really affect the
> > time spent generating code.
> > (Anybody with real experience in this area please correct me!)
>
> Don't forget that Turbo Pascal was originally written in assembly
> language. The compiler itself was highly optimized (though not an
> optimizing compiler) for performance, hence the moniker. Also, the
> nested functions can speed things up a bit since they allow the
> compiler to reduce the size of the symbol table.


Only if there are many nested functions. Most Pascal code that I have
seen (or written) doesn't have many of them.


> Also, Pascal, the language, was designed to be compilable by a
> single-pass compiler, C was not.


Correct, but if you look at the details, there aren't many differences
that require time to compile. (There are things that are difficult to
do correctly, like determining what's a type name and what's a
function name during parsing in C, or like establishing access to the
local variables of an enclosing subroutine, but executing these
difficult algorithms shouldn't take time.)


> Also, Turbo Pascal incorporated the linker (a not-too-insignificant
> task in C) directly into the compiler


There's no significant difference in what a C or a Pascal linker would
have to do. A Pascal linker *could* do more type checking, but that's
just a comparison of a handful of bytes, which should be on the same
order of magnitude as just looking up the symbol in the symbol table
(and both activities should be insignificant when comparing to the
address fix-up phase where there's a symbol look-up and a longword
write for each linked symbol).


IOW I don't think that a C compiler need be slower than Turbo Pascal.


Wait... I recently saw the C compiler embedded into LabView (a virtual
measurement platform sold by National Instruments), and compilation
times were unnoticeable. That's just anecdotal evidence, and the C
code wasn't that much anyway, but it was still much faster than Visual
C++.


Some other potential problems:


3) There ain't no Real C Compilers anymore, if you compile C you
always get the overhead for C++. (I don't know what that overhead
would be though. Template instantiation seems to involve backtracking,
but then most C++ programs don't instantiate that many templates.)


4) Compiling a program of size N is an N log N task (because there are
more symbols to select from). In C, the overhead for accessing another
module is higher (because the compiler has to recompile the header
files), and since it's difficult to select exactly those header files
that are needed for a module, people tend to just include everything
in every module and end up with an N*N task. (Precompiled headers
prevent that N*N blowup, but they come with a large constant factor it
seems.) An extremely common example of this type of blowup is the
practice of just including <windows.h> in any Windows
program. <windows.h> with all its indirectly included files is a
monster of roughly 2.5 MB IIRC, and it goes *far* beyond what any real
Windows software needs - but trimming down on the required include
files takes too much programmer time so it's virtually never done.


Again, just guesswork. I'd love to see numbers from a C compiler with
times from the various passes.


> and Turbo's UNIT object code format made it very easy to quickly
> link in separately compiled modules.


In what ways?


Regards,
Joachim

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