Re: Using C as a back end

Randall Hyde <rhyde@cs.ucr.edu>
1 Nov 2000 18:52:22 -0500

          From comp.compilers

Related articles
[20 earlier articles]
Re: Using C as a back end thp@cs.ucr.edu (Tom Payne) (2000-10-31)
Re: Using C as a back end engler@Stanford.EDU (2000-10-31)
Re: Using C as a back end anton@mips.complang.tuwien.ac.at (2000-10-31)
Re: Using C as a back end joachim_d@gmx.de (Joachim Durchholz) (2000-10-31)
Re: Using C as a back end conway@ender.cs.mu.oz.au (2000-11-01)
Re: Using C as a back end kst@cts.com (Keith Thompson) (2000-11-01)
Re: Using C as a back end rhyde@cs.ucr.edu (Randall Hyde) (2000-11-01)
Re: Using C as a back end rhyde@cs.ucr.edu (Randall Hyde) (2000-11-01)
Re: Using C as a back end vbdis@aol.com (2000-11-04)
Re: Using C as a back end joachim_d@gmx.de (Joachim Durchholz) (2000-11-04)
Re: Using C as a back end thp@roam-thp2.cs.ucr.edu (Tom Payne) (2000-11-04)
Re: Using C as a back end gneuner@dyn.com (2000-11-04)
Re: Using C as a back end fjh@cs.mu.OZ.AU (2000-11-05)
[2 later articles]
| List of all articles for this month |

From: Randall Hyde <rhyde@cs.ucr.edu>
Newsgroups: comp.compilers
Date: 1 Nov 2000 18:52:22 -0500
Organization: Posted via Supernews, http://www.supernews.com
References: 00-10-148 00-10-164 00-10-205 00-10-234
Keywords: C, Pascal, UNCOL
Posted-Date: 01 Nov 2000 18:52:22 EST

Joachim Durchholz at joachim_d@gmx.de wrote on 10/31/00 12:43 PM:


> 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. Also, Pascal, the
language, was designed to be compilable by a single-pass compiler, C
was not. Also, Turbo Pascal incorporated the linker (a
not-too-insignificant task in C) directly into the compiler and
Turbo's UNIT object code format made it very easy to quickly link in
separately compiled modules.


> (2) is a good candidate. Turbo Pascal always emitted horribly bad
> code. So it seems that many C compilers spend a *lot* of time
> optimizing the generated code. Anybody with concrete numbers from
> compiler passes to back or falsify this hypothesis?


IIRC, recent Turbo Pascal compilers and Delphi uses (one of) the same
back end(s) as the Borland C++ offering. This explains recent speed
drops in the Pascal/Delphi compiler (though more than offset by
increased CPU speeds).


BTW, even if you turn optimization off, most C++ compilers are still
slower than most Pascal compilers. So my guess is that the
single-pass design of Pascal is a large contributing factor.


Randy Hyde


Post a followup to this message

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