Lisp to C conversion

[johnl at ima.UUCP]

/* Written  1:57 am  Dec  8, 1985 by levy at ttrdc in ima:net.lang.c */
> >Did you ever consider that ALL programs which don't read any input
> >(e.g. a program to calculate the first 1000 digits of pi) would be,
> >theoretically, totally consumed by true "optimizing" compilers?
> >That is, you tell the compiler to optimize your pi-calculating program
> >and it spews out "3.14159..."

> That would be a marvel of "artificial intelligence" -- an optimizer that
> can recognize algorithms.

Not at all.  It's just aggressive constant folding.  It's not hard for a
compiler to tell that some piece of a program has no inputs, and once it's
figured that out, it can compute the result of that piece at compile time
and substitute its result.  Compilers for traditional sorts of languages
like Fortran and C generally don't do very much of that because they don't
usually look across routine boundaries, but I've seen great stuff in some
Lisp compilers.  Since practically everything in Lisp is a function call, the
only way a compiler can do any good is to look into functions and tell that,
for example, a call to (car foo) can be turned into one or two instructions
that fetch the car part of foo.  Lisp compilers do more in-line expansion of
small functions than they do constant folding, because the gain in most Lisp
code is greater, but there's no reason they can't do both.

The upshot of this is that I agree that your typical algorithm would run
faster compiled by a typical C compiler than by a typical Lisp compiler, but
that's because both compilers have serious blind spots in their optimizations,
and C wins because it was designed to be easier to compile.

John Levine, ima!johnl